Skip to main content

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

Low

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. Identify alpha clusters
    • Run on any machine with gcloud configured:
    • For each cluster, check whether it has alpha enabled:
    • Record clusters where this value is true.
  2. Determine whether the alpha cluster is used for production
    • For each cluster with .enableKubernetesAlpha == true, collect workload and usage evidence (from any machine with gcloud and, if desired, kubectl):
    • Review: namespaces, workload names, labels/annotations, SLAs, and whether this cluster serves any production traffic or critical systems.
  3. 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.
  4. 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:
  5. Migrate production workloads off alpha clusters
    • From any machine with kubectl access 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.
  6. 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 == true is documented and treated as non‑production; no production workloads should remain on such clusters.
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.
How to run (from any machine with gcloud access)
How to interpret the output
  • The script prints a CSV with columns: project,location,cluster,enableKubernetesAlpha.
  • Any row where enableKubernetesAlpha is true indicates 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.