GKE Security Best Practices: From IAM Vulnerabilities to Pod Security

  • 24/1/2024
  • One-minute read

Research highlighted that granting the cluster-admin role to the implicit system:authenticated group exposes GKE clusters: any Google account can authenticate and escalate privileges. Similar misconfigurations occur when legacy service accounts or default groups retain broad permissions.

Hardening Checklist

  1. Review IAM Bindings: Audit your project/cluster IAM policies (gcloud projects get-iam-policy). Remove cluster-admin or broad roles from wildcard identities.
  2. Enforce RBAC Least Privilege:
    • Use fine-grained Role/RoleBinding objects per namespace.
    • Prefer short-lived gcloud container clusters get-credentials tokens; disable legacy basic authentication.
  3. Adopt Workload Identity: Map Kubernetes service accounts to Google service accounts; avoid sharing long-lived JSON keys.
  4. Enable Pod Security Admission: Label namespaces with pod-security.kubernetes.io/enforce=baseline or restricted. PodSecurityPolicy is deprecated/removed in modern GKE releases.
  5. Restrict API Server Access: Use private clusters, authorised networks, or Cloud Armor to limit control-plane exposure.
  6. Monitor & Alert: Stream audit logs to Cloud Logging and configure Security Command Center or Chronicle to detect unusual RBAC grants.

Operational Tips

  • Rotate service-account keys and disable unused ones (gcloud iam service-accounts keys list/delete).
  • Implement admission controllers (OPA/Gatekeeper, Kyverno) to block privileged pods and hostPath mounts.
  • Keep clusters patched (regular release channels or auto-upgrade) and review release notes for security fixes.

References

GKEKubernetesCloud-SecurityCybersecurityIAMRBACPod-SecurityWorkload-Identity