fix: x509 client certificates based authentication is not working with Canonical K8s snap

[MoeSalah1999]

Description

Fixes x509 client-certificate authentication for certificates issued through the Kubernetes CSR flow in the Canonical K8s snap.

Previously, CSRs approved with kubectl certificate approve could be signed by the wrong CA for API server client authentication. The API server validates client certificates against /etc/kubernetes/pki/client-ca.crt, so CSR-issued client certificates must be signed by the corresponding client CA, not the general Kubernetes CA.

Solution

1. Updated the kube-controller-manager service wrapper to pass the client CA as the default cluster signing CA:

• --cluster-signing-cert-file=/etc/kubernetes/pki/client-ca.crt
• --cluster-signing-key-file=/etc/kubernetes/pki/client-ca.key

2. Added guard logic so this override is only applied when:

• the controller-manager args file does not exist,
• the args file does not define cluster signing cert/key flags, or
• the args file still points cluster signing to the general Kubernetes CA:
  • /etc/kubernetes/pki/ca.crt
  • /etc/kubernetes/pki/ca.key

3. Preserved user/custom configuration by not overriding cluster signing flags when they are already explicitly configured to another value.

4. Added an integration regression test that:

• creates a private key and CSR for a test client,
• submits a Kubernetes CertificateSigningRequest using signer kubernetes.io/kube-apiserver-client,
• approves the CSR with kubectl certificate approve,
• waits for .status.certificate because CSR signing is asynchronous,
• decodes the issued certificate,
• verifies it chains to /etc/kubernetes/pki/client-ca.crt,
• builds a kubeconfig using the issued client certificate,
• confirms the issued certificate can authenticate to the API server.

5. Updated certificate documentation to clarify that:

• client-ca is the CA used for client certificates,
• its generated certificate common name is kubernetes-ca-client,
• approved Kubernetes CSRs are signed with this client CA so the resulting certificates are trusted by the API server’s client-ca.crt bundle.

Why this approach?
Instead of patching Kubernetes source defaults, this fixes the snap’s runtime configuration directly through the existing service wrapper mechanism. This avoids carrying fragile Kubernetes source patches and keeps the behavior aligned with the snap’s generated controller-manager args.

The wrapper also avoids overwriting explicit custom cluster-signing settings, so users can still configure a different signing CA if needed.

Issue

Issue #2448

Backport

Checklist

• PR title formatted as type: title
• Covered by unit tests
• Covered by integration tests
• Documentation updated
• CLA signed
• Backport label added if necessary
• Confirm whether the release-notes label should be kept or removed

If any item on the checklist is not complete, please provide justification why.

[MoeSalah1999]

@bschimke95 Could you please verify this?

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.