Gke Platform Security

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

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 clustergcloud 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 disabledgcloud 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 Authorizationgcloud 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 clustergcloud container clusters update <CLUSTER_NAME> --region <REGION> \  --enable-shielded-nodes \  --quiet
# Enable GKE Sandbox (gVisor) runtime on an existing clustergcloud 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:

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 objectsgcloud 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 databasesgcloud 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 subscriptionsgcloud 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)