gke-security

name	gke-security
description	Plans, configures, and hardens Google Kubernetes Engine (GKE) security. Covers Workload Identity Federation, Secret Manager integration, RBAC hardening, Binary Authorization, Network Policies (Dataplane V2), Pod Security Standards, and IAM roles. Use when securing GKE clusters, setting up Workload Identity, hardening RBAC configurations, or configuring GKE secrets. Don't use for general network routing configuration (use gke-networking instead).
metadata	{"category":"Security"}

GKE Security

This reference covers security configuration for GKE clusters. The golden path enforces a hardened security posture by default.

MCP Tools: get_cluster, check_k8s_auth, get_k8s_resource, apply_k8s_manifest, 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 Pods
secretManagerConfig.enabled	true	Day-1	Google Secret Manager integration
secretManagerConfig.rotationConfig	enabled: true, rotationInterval: 120s	Day-1	Automatic secret rotation
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

Workload Identity Federation

Workload Identity is the recommended way for pods to access Google Cloud APIs. It eliminates the need for static service account keys.

Setup

# 1. Create a Google Service Account (GSA)
gcloud iam service-accounts create <GSA_NAME> \
  --project <PROJECT_ID> \
  --display-name "Workload Identity SA" \
  --quiet

# 2. Grant IAM roles to the GSA
gcloud projects add-iam-policy-binding <PROJECT_ID> \
  --member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
  --role "<ROLE>" \
  --quiet

# 3. Create Kubernetes Service Account (KSA)
kubectl create namespace <NAMESPACE>
kubectl create serviceaccount <KSA_NAME> --namespace <NAMESPACE>

# 4. Bind KSA to GSA
gcloud iam service-accounts add-iam-policy-binding \
  <GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:<PROJECT_ID>.svc.id.goog[<NAMESPACE>/<KSA_NAME>]" \
  --quiet

# 5. Annotate KSA
kubectl annotate serviceaccount <KSA_NAME> \
  --namespace <NAMESPACE> \
  iam.gke.io/gcp-service-account=<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com

See assets/workload-identity-pod.yaml for a test pod.

Verification

kubectl run workload-identity-test \
  --image=gcr.io/google.com/cloudsdktool/cloud-sdk:slim \
  --serviceaccount=<KSA_NAME> --namespace=<NAMESPACE> \
  --rm -it -- gcloud auth list --quiet

Secret Manager Integration

The golden path enables Secret Manager with automatic rotation. Secrets are synced to Kubernetes Secrets.

# 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

Mounting Secrets via CSI Volume (Deployment Example)

Once the Secret Manager add-on is enabled, workloads can mount secrets as volumes using the Secrets Store CSI driver. This requires two steps:

1. Define a SecretProviderClass to specify which secrets to retrieve from Secret Manager.
2. Mount the volume in a Deployment referencing that class.

[!IMPORTANT] Production Best Practice: Always demonstrate workload integrations (like Secret Manager CSI) using production-standard Deployment manifests rather than raw Pod manifests.

Step 1: Create the SecretProviderClass

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: app-secrets-provider
  namespace: default
spec:
  provider: gke  # Identifies GKE managed provider
  parameters:
    secrets: |
      - resourceName: "projects/<PROJECT_ID>/secrets/db-password/versions/latest"
        fileName: "db-password.txt"

Step 2: Mount the secret in a Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: secure-app
  template:
    metadata:
      labels:
        app: secure-app
    spec:
      serviceAccountName: secure-ksa  # Must be bound to GSA with Secret Manager Secret Accessor role
      containers:
      - name: app
        image: <IMAGE>
        volumeMounts:
        - name: secrets-volume
          mountPath: "/var/secrets"
          readOnly: true
      volumes:
      - name: secrets-volume
        csi:
          driver: secrets-store.csi.k8s.io
          readOnly: true
          volumeAttributes:
            secretProviderClass: "app-secrets-provider"

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
• Audit permissions via MCP: check_k8s_auth(parent="...", verb="list", resourceType="pods", namespace="...") (or kubectl auth can-i --list --as=<user>)
• Review bindings via MCP: 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 production image provenance:

# Enable Binary Authorization
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
  --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
  --quiet

Network Policies

Dataplane V2 (golden path) provides built-in Network Policy enforcement. Apply default-deny per namespace:

# MCP (preferred)
apply_k8s_manifest(parent="...", yamlManifest="<contents of default-deny-netpol.yaml>")

# kubectl fallback
kubectl apply -f ./assets/default-deny-netpol.yaml -n <NAMESPACE>

GKE Sandbox (gVisor)

For running untrusted workloads in an isolated sandbox:

# Enable on cluster (Standard clusters)
gcloud container clusters update <CLUSTER_NAME> --region <REGION> --enable-gke-sandbox --quiet

# Use in pod spec
# Add: runtimeClassName: gvisor

Pod Security Standards (Golden Path)

Pod Security Standards define three profiles that restrict what pods can do. The restricted profile is the golden path default for production namespaces.

Profile	Level	Use Case
privileged	Unrestricted	System namespaces (kube-system),
: : : infrastructure controllers :
baseline	Minimally restrictive	Shared/dev namespaces, legacy apps
: : : being migrated :
restricted	Golden path	Production workloads -- blocks
: : : privilege escalation, host access, :
: : : root :

Enforce via namespace labels (Pod Security Admission):

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Gradual rollout strategy:

1. Start with warn + audit on existing namespaces to identify violations
2. Fix non-compliant workloads (remove privileged, hostNetwork, root user, etc.)
3. Enable enforce once all workloads pass

restricted blocks: running as root, privilege escalation, host networking/PID/IPC, host path volumes, and most capabilities. The golden path workload-identity-pod.yaml already complies.

Network Policy Logging (Recommended)

With Dataplane V2 (golden path), you can enable logging for Network Policy decisions. Not a golden path default -- recommended for security auditing.

gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
  --enable-network-policy-logging \
  --quiet

This logs allowed and denied connections, useful for troubleshooting Network Policy rules and auditing traffic flows.

Common IAM Roles

The five most common predefined IAM roles for GKE:

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.

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, create a dedicated SA with minimal permissions and assign it via node pool config.
• Workload Identity: The recommended way for pods to access Google Cloud APIs. Maps a Kubernetes ServiceAccount to a Google IAM ServiceAccount — see Workload Identity setup above.

Cross-Service Authentication Patterns

Common patterns for granting GKE workloads access to other Google Cloud services:

# Grant a GKE workload access to Cloud Storage
gcloud projects add-iam-policy-binding <PROJECT_ID> \
  --member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
  --role "roles/storage.objectViewer" \
  --quiet

# Grant a GKE workload access to Cloud SQL
gcloud projects add-iam-policy-binding <PROJECT_ID> \
  --member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
  --role "roles/cloudsql.client" \
  --quiet

# Grant a GKE workload access to Pub/Sub
gcloud projects add-iam-policy-binding <PROJECT_ID> \
  --member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
  --role "roles/pubsub.subscriber" \
  --quiet

In all cases, the GSA must be bound to a KSA via Workload Identity (see setup above). The pod then uses the KSA to authenticate as the GSA.