GKE Platform Security
This reference covers platform-level security hardening and cluster
configuration for Google Kubernetes Engine (GKE). For workload-level security
controls (such as Workload Identity Service Account bindings,
SecretProviderClass volume mounts, Network Policies, and Pod Security
Standards), refer to the gke-workload-security skill.
MCP Tools: gke:get_cluster, k8s:check_k8s_auth,
k8s:get_k8s_resource, k8s:apply_k8s_manifest, gke:update_cluster
Golden Path Security Defaults
| Setting | Golden Path Value | Day-0/1 | Notes |
|---|
workloadIdentityConfig.workloadPool | <PROJECT>.svc.id.goog | Day-0 | Workload Identity Federation for cluster pods |
secretManagerConfig.enabled | true | Day-1 | Google Secret Manager cluster add-on integration |
secretManagerConfig.rotationConfig | enabled: true, rotationInterval: 120s | Day-1 | Automatic secret rotation at the cluster level |
rbacBindingConfig.enableInsecureBindingSystemAuthenticated | false | Day-0 | Blocks legacy system:authenticated bindings |
rbacBindingConfig.enableInsecureBindingSystemUnauthenticated | false | Day-0 | Blocks legacy system:unauthenticated bindings |
nodeConfig.shieldedInstanceConfig.enableSecureBoot | true | Day-0 | Verifiable boot integrity |
nodeConfig.shieldedInstanceConfig.enableIntegrityMonitoring | true | Day-0 | Runtime integrity checks |
nodeConfig.workloadMetadataConfig.mode | GKE_METADATA | Day-0 | Blocks legacy metadata API, enforces Workload Identity |
| Private cluster + Dataplane V2 settings | See the gke-networking skill | Day-0 | Private nodes, private endpoint enforcement, ADVANCED_DATAPATH |
Secret Manager Add-on Enablement
The golden path enables Secret Manager at the cluster level with automatic
secret rotation.
# Verify Secret Manager is enabled on cluster
gcloud container clusters describe <CLUSTER_NAME> --region <REGION> \
--format="value(secretManagerConfig.enabled)" \
--quiet
# Enable if not already (Day-1 change)
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
--enable-secret-manager \
--secret-manager-rotation-interval=120s \
--quiet
Note: For configuring SecretProviderClass manifests and mounting secrets
as volumes inside application deployments, see the gke-workload-security
skill.
RBAC Hardening
The golden path disables insecure legacy RBAC bindings that grant broad access
to system:authenticated and system:unauthenticated groups.
# Verify insecure bindings are disabled
gcloud container clusters describe <CLUSTER_NAME> --region <REGION> \
--format="yaml(rbacBindingConfig)" \
--quiet
Best practices for RBAC:
- Use namespace-scoped Roles over cluster-wide ClusterRoles.
- Bind to specific Groups or ServiceAccounts, never to
system:authenticated
or system:unauthenticated.
- Audit permissions via MCP:
k8s:check_k8s_auth(parent="...", verb="list", resourceType="pods", namespace="...") (or kubectl auth can-i --list --as=<user>).
- Review bindings via MCP:
k8s:get_k8s_resource(parent="...", resourceType="clusterrolebinding") (or kubectl get clusterrolebindings,rolebindings --all-namespaces).
See the gke-multitenancy skill for enterprise RBAC planning and
https://docs.cloud.google.com/kubernetes-engine/docs/best-practices/rbac.md.txt
Binary Authorization
Not enabled in golden path by default but recommended for enforcing production
image provenance across the cluster:
# Enable Binary Authorization
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
--quiet
Shielded Nodes & GKE Sandbox Enablement
Enabling verifiable node boot integrity and kernel isolation features at the
cluster level:
# Enable Shielded Nodes on an existing cluster
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
--enable-shielded-nodes \
--quiet
# Enable GKE Sandbox (gVisor) runtime on an existing cluster
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
--enable-gke-sandbox \
--quiet
Note: To run workloads inside the gVisor sandbox, specify
runtimeClassName: gvisor in your Pod specs as detailed in the
gke-workload-security skill.
Common IAM Roles
The five most common predefined IAM roles for GKE platform and cluster access:
| Role | Purpose | When to Use |
|---|
roles/container.admin | Full control over | Platform team admins |
| : : clusters and : managing cluster : | | |
| : : Kubernetes : lifecycle : | | |
| : : resources : : | | |
roles/container.clusterAdmin | Manage clusters but | Cluster operators |
| : : not project-level : who create/delete : | | |
| : : IAM : clusters : | | |
roles/container.developer | Deploy workloads | Application |
| : : (pods, services, : developers deploying : | | |
| : : deployments) : to existing clusters : | | |
roles/container.viewer | Read-only access to | Monitoring, |
| : : clusters and : auditing, or : | | |
| : : Kubernetes : read-only dashboards : | | |
| : : resources : : | | |
roles/container.clusterViewer | List and get | CI/CD pipelines that |
| : : cluster details : need cluster : | | |
| : : only : metadata : | | |
Principle of least privilege: Start with roles/container.viewer or
roles/container.developer and escalate only as needed. Avoid granting
roles/container.admin broadly across teams.
Service Accounts & Agents
- GKE Service Agent
(
service-<PROJECT_NUMBER>@container-engine-robot.iam.gserviceaccount.com):
Automatically created. Manages nodes, networking, and cluster operations on
your behalf. Do not remove or modify its permissions.
- Node Service Account: By default, nodes use the Compute Engine default
service account. For production platforms, create a dedicated Google Service
Account with minimal required permissions (
roles/monitoring.metricWriter,
roles/logging.logWriter) and assign it at node pool creation time.
- Workload Identity: For binding Google Service Accounts to Kubernetes
Service Accounts (
roles/iam.workloadIdentityUser), refer to the
gke-workload-security skill.
Cross-Service Authentication Patterns
Common project-level IAM policy binding patterns for granting backend Google
Service Accounts (GSAs) access to external Google Cloud services before linking
via Workload Identity:
# Grant a GSA access to Cloud Storage objects
gcloud projects add-iam-policy-binding <PROJECT_ID> \
--member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
--role "roles/storage.objectViewer" \
--quiet
# Grant a GSA access to Cloud SQL databases
gcloud projects add-iam-policy-binding <PROJECT_ID> \
--member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
--role "roles/cloudsql.client" \
--quiet
# Grant a GSA access to Pub/Sub subscriptions
gcloud projects add-iam-policy-binding <PROJECT_ID> \
--member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
--role "roles/pubsub.subscriber" \
--quiet
## Resources
- [GKE Cluster Hardening Guide](https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster)
- [GKE RBAC Best Practices](https://cloud.google.com/kubernetes-engine/docs/best-practices/rbac)
- [Secret Manager Add-on for GKE](https://cloud.google.com/secret-manager/docs/secret-manager-managed-csi-component)
- [Binary Authorization on GKE](https://cloud.google.com/binary-authorization/docs/setting-up)
- [Shielded GKE Nodes](https://cloud.google.com/kubernetes-engine/docs/how-to/shielded-gke-nodes)
- [GKE Sandbox (gVisor)](https://cloud.google.com/kubernetes-engine/docs/how-to/sandbox-pods)