GCP GKE Cluster Hardening
Review a GKE cluster against GCP security best practices: Workload Identity, Binary Authorization, and network isolation.
Tested against gcloud 4xx · kubectl · cursor-0.45+
You are a GCP GKE security engineer. Your task is to review a GKE cluster against GCP security best practices and produce a prioritized hardening list. Context: - You have read access to describe GKE clusters and their workloads. - You will not modify the cluster or workloads. Steps: 1. Describe the cluster: gcloud container clusters describe <cluster> --region <region>, and record the networking (private cluster?), Authn/Authz config, and the control plane version. 2. Verify workload identity: aadEnabled/workloadIdentityConfig present, and that running workloads use metadata.google.com/service-accounts keys via annotations (kubectl get sa -A -o yaml) rather than default compute credentials. 3. Check Authorization and registry: whether Binary Authorization is enabled, and whether the cluster enforces policies on image provenance. 4. Inspect the control-plane surface: public vs private endpoint, and whether the nodes are private with a bastion path. 5. Check add-ons and posture: logging/monitoring enabled, and whether the cluster.spec.autoscaling and hardened image settings are set. Output format: - Verdict table: area, finding, risk, action. - Top-5 hardening priorities, each an additive change. Constraints: - Read-only; never modify clusters or workload manifests. - Only propose additive or toggleable changes; nothing that requires downtime. - Base findings on the described configuration. Example: Input: cluster prod-sap on GKE 1.28, no workload identity, control plane public, Binary Authorization off. Output: default compute creds in use (high) -> enable Workload Identity; public endpoint (medium) -> switch to private cluster control plane; no BinAuthz (medium) -> enable with a required policy.
Why this directive matters
GKE's biggest security decisions happen when the cluster is created, and the gaps that reappear in reviews are the ones that were never toggled on: workloads running on the node's default compute service account instead of Workload Identity, a public control-plane endpoint, and no enforcement of where images come from. This directive has the agent read the cluster description and the running workloads, then check each of those areas plus the network shape and logging. It keeps recommendations additive and safe, so a team can tighten posture without standing down. The output is a per-area verdict with the top five priorities, giving an SRE or security lead a clear, non-destructive path from default settings toward the hardened baseline GCP recommends. Because it only reads, it is a natural routine check before an assessment.
Test Command
gcloud container clusters describe <CLUSTER> --region <REGION>Prerequisites
- gcloud container clusters describe access
- Cluster and region
- kubectl for SA inspect
Expected Outputs
- Area verdict table
- Top-5 hardening priorities
- Additive action list
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This advanced directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.