Detections
Analytics

5.8.1 Disable legacy client certificate authentication for the GKE API server

Information

Disable legacy client certificate authentication for the GKE API server by ensuring GKE does not issue a pre provisioned client certificate for cluster access. Use supported identity based authentication methods, such as OAuth tokens through gcloud, service account bearer tokens, or approved external identity provider authentication instead of long lived static client certificates.

Legacy client certificates are harder to govern than identity based authentication because they are long lived credentials and are not managed through normal IAM user lifecycle controls. If a client certificate is exposed, access can persist until the certificate expires or the cluster certificate authority is rotated, which makes containment and revocation more operationally disruptive than disabling a user, group, or service account permission.

GKE supports multiple Kubernetes API server authentication methods, including OAuth tokens, service account bearer tokens, and X.509 client certificates. For administrator access, the gcloud CLI uses OAuth tokens, which reduces the need for legacy static credentials. Disabling GKE client certificate issuance prevents GKE from providing the legacy client certificate, but it does not disable the Kubernetes certificates API, which is used by the cluster and cannot be disabled.

Solution

For new clusters, create the cluster without issuing a legacy client certificate by using the --no-issue-client-certificate flag.

gcloud container clusters create $CLUSTER_NAME \\
 --location $LOCATION \\
 --project $PROJECT_ID \\
 --no-issue-client-certificate

For existing clusters where a legacy client certificate was already issued, GKE does not provide a direct method to remove that client certificate from the cluster. To fully remediate the setting, create a replacement cluster with --no-issue-client-certificate, migrate workloads, validate access, and decommission the old cluster after migration.

Note: If immediate replacement is not practical, reduce risk on the existing cluster by ensuring RBAC is enabled and that the legacy client certificate has no Kubernetes RBAC permissions. Also review RBAC permissions for the Kubernetes CertificateSigningRequest API so only approved administrative identities can create or approve certificate requests. The --no-issue-client-certificate flag disables legacy GKE client certificate issuance, but it does not disable the Kubernetes certificates API, which is required for cluster operation.

Impact:

Users or automation that still rely on the pre provisioned x509 client certificate will no longer be able to authenticate with that credential and must be updated to use approved authentication methods. Existing access workflows, kubeconfig files, CI/CD integrations, and break glass procedures should be reviewed before enforcement to avoid disrupting legitimate cluster administration.

See Also

https://workbench.cisecurity.org/benchmarks/24956

Item Details

Category: ACCESS CONTROL, AUDIT AND ACCOUNTABILITY

References: 800-53|AC-2, 800-53|AC-3, 800-53|AC-6, 800-53|AC-6(1), 800-53|AC-6(7), 800-53|AU-9(4), CSCv7|16

Plugin: GCP

Control ID: 0aa57a6d32bd6ee3493f6489ba3304d890c9bac48166958acacf2b2bc221b441