More Info:
Do not run production workloads on alpha clusters, which enable unsupported features, lack SLAs, and cannot be upgraded. Use standard clusters for production.Risk Level
LowAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify alpha clusters
- Run on any machine with
gcloudconfigured: - For each cluster, check whether it has alpha enabled:
- Record clusters where this value is
true.
- Run on any machine with
-
Determine whether the alpha cluster is used for production
- For each cluster with
.enableKubernetesAlpha == true, collect workload and usage evidence (from any machine withgcloudand, if desired,kubectl): - Review: namespaces, workload names, labels/annotations, SLAs, and whether this cluster serves any production traffic or critical systems.
- For each cluster with
-
Decide the disposition for each alpha cluster
- For each alpha cluster flagged as production or unclear, decide one of:
- Not production → keep as non-production (e.g., explicitly mark as dev/test) and ensure no production workloads are scheduled there.
- Production or mixed → plan to migrate all production workloads to a non-alpha cluster and then decommission the alpha cluster.
- Document the decision, business owner, and target timeline.
- For each alpha cluster flagged as production or unclear, decide one of:
-
Provision or identify a non‑alpha replacement cluster (if needed)
- If you need a new cluster for production workloads, create it without enabling alpha (run on any machine with
gcloud): - Confirm alpha is disabled:
- If you need a new cluster for production workloads, create it without enabling alpha (run on any machine with
-
Migrate production workloads off alpha clusters
- From any machine with
kubectlaccess to both clusters, export manifests from the alpha cluster and apply them to the non‑alpha cluster, adapting as needed: - Update DNS, load balancers, and client configuration as needed to point to the new cluster, and validate application behavior and traffic.
- From any machine with
-
Decommission or reclassify alpha clusters and verify
- If the alpha cluster is no longer needed for production (ideally no workloads remain, or it is explicitly dev/test), either delete it or document its non‑production role:
- Re-run the audit for all remaining clusters to confirm compliance (any alpha clusters must now be clearly non‑production):
- Ensure any cluster with
.enableKubernetesAlpha == trueis documented and treated as non‑production; no production workloads should remain on such clusters.
- If the alpha cluster is no longer needed for production (ideally no workloads remain, or it is explicitly dev/test), either delete it or document its non‑production role:
Using kubectl
Using kubectl
kubectl cannot change whether a GKE cluster was created with
--enable-kubernetes-alpha; that setting is part of the managed control-plane configuration in GCP (console/CLI/IaC), not a Kubernetes API object. To address this finding, follow the guidance in the Manual Steps section using the Google Cloud Console, gcloud, or your IaC definitions.Automation
Automation
- The script prints a CSV with columns:
project,location,cluster,enableKubernetesAlpha. - Any row where
enableKubernetesAlphaistrueindicates a cluster created with Kubernetes Alpha enabled. - Such clusters must be treated as non‑production. If they currently host production workloads, this violates the control and requires architectural and migration review, not an in-place automated fix.

