Google CloudOverview
A client certificate is a base64-encoded public certificate used by clients to authenticate to the cluster endpoint.
Rationale
If you disable client certificate generation to create a cluster without a client certificate. You will still be able to authenticate to the cluster with basic auth or IAM. But basic auth allows a user to authenticate to the cluster with a username and password which are stored in plain text without any encryption and might lead brute force attacks.
Remediation guidance
Using Console
- Go to Kubernetes GCP Console by visiting https://console.cloud.google.com/kubernetes/list?
- Click on CREATE CLUSTER
- Choose required name/value for cluster fields
- Click on More
- Set Client certificate to Enabled
- Click on Create
Using Command Line
To enable Network policy for an existing cluster, run the following command:
gcloud container clusters create \[CLUSTER_NAME\] --zone \[COMPUTE_ZONE\] --issue-client-certificate
Impact
Cluster create command will create a new cluster with Client certificate enabled, But already existing once are remains unchanged.
Default Value
By default, the Client certificate is enabled when you create a new cluster.
References
- https://cloud.google.com/sdk/gcloud/reference/container/clusters/create
Multiple Remediation Paths
Google Cloud
SERVICE-WIDE (RECOMMENDED when many resources are affected): Enforce Organization Policies at org/folder level so new resources inherit secure defaults.
gcloud org-policies set-policy policy.yaml
ASSET-LEVEL: Use the product-specific remediation steps above for only the impacted project/resources.
PREVENTIVE: Use org policy constraints/custom constraints and enforce checks in deployment pipelines.
References for Service-Wide Patterns
- GCP Organization Policy overview: https://cloud.google.com/resource-manager/docs/organization-policy/overview
- GCP Organization policy constraints catalog: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
- gcloud org-policies: https://cloud.google.com/sdk/gcloud/reference/org-policies
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Google Cloud: apply organization policy constraints at org/folder scope.
gcloud org-policies set-policy policy.yaml
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
Kubernetes Cluster is created with Client Certificate enabled
Connectors
Covered asset types
Expected check: eq []
gkeClusters(where:{masterAuthClientKey:""}){...AssetFragment}
