GKE Security Best Practices: How to Secure Google Kubernetes Engine

Simple explanation

GKE security works in layers because each layer protects against a different type of failure:

• Identity and IAM: controls who can call Google Cloud APIs from inside the cluster
• Kubernetes RBAC: controls who can interact with the Kubernetes API — creating pods, reading secrets, and so on
• Node security: protects the machines the cluster runs on from tampering at boot time
• Network controls: restricts which pods can reach which other pods, and who can reach the control plane
• Image security: ensures that only verified, scanned images make it into production
• Secrets protection: prevents sensitive values from being stored or retrieved insecurely
• Logging and monitoring: gives you the visibility to detect problems when other controls are bypassed or misconfigured

If you skip one layer, a failure in an adjacent area can cascade across the whole cluster. That is why production security covers all of these areas, not just one or two.

How GKE cluster security works

GKE is a managed Kubernetes service. Google manages the control plane, but you are responsible for configuring the security of your cluster, its workloads, and the identities that access it.

Here is how the layers connect:

Step 1: Access to the control plane. The Kubernetes API server is the entry point for all cluster operations. Restricting who can reach it (using authorised networks or a private endpoint) and who can authenticate to it (using Google Cloud IAM and Kubernetes RBAC) is the first line of defence.

Step 2: What pods are allowed to do. Pods run under a Kubernetes ServiceAccount. With Workload Identity, that ServiceAccount is bound to a Google Cloud IAM service account, so pods receive scoped, short-lived credentials automatically. Without Workload Identity, pods fall back to the node’s service account, carrying whatever permissions the node was given.

Step 3: Node integrity. Shielded GKE Nodes use hardware-level attestation to verify that a node booted without tampering. Container-Optimized OS reduces the attack surface by removing unnecessary software from the node image.

Step 4: Pod-to-pod and pod-to-external traffic. By default, all pods in a GKE cluster can communicate with each other. NetworkPolicy restricts this to only the connections that are explicitly required. Private clusters remove node IP addresses from the public internet entirely.

Step 5: What images can run. Artifact Registry scans images for known CVEs. Binary Authorization enforces a deploy-time policy requiring that an image has been cryptographically attested before GKE will allow it to run.

Step 6: Secrets. Kubernetes Secrets are base64-encoded in etcd by default, not encrypted. Application-layer encryption via Cloud KMS, or routing secrets through Secret Manager entirely, keeps sensitive values protected even if someone gains etcd access.

Step 7: Logging and detection. Cloud Audit Logs record every API call against the cluster. Logging in Kubernetes surfaces workload output. Security Command Center surfaces GKE-specific misconfigurations and threats automatically.

Each of these steps depends on the others. A perfectly configured RBAC policy does not help if a misconfigured node service account gives every pod broad IAM access. A private cluster does not help if an unscanned image runs a known exploit. The layers reinforce each other.

When to use this approach

Apply the full layered security model when:

• Running production workloads: any cluster where data loss, service disruption, or credential theft would have a real impact
• Handling regulated or sensitive data: PCI, HIPAA, SOC 2, and similar frameworks often mandate specific controls like encryption at rest and audit logging
• Multi-team clusters: when different teams share a cluster, RBAC, namespace isolation, and NetworkPolicy prevent one team’s misconfigured workload from affecting others
• Internet-facing services: workloads exposed to the internet have a larger attack surface and warrant tighter network controls and image verification
• CI/CD pipelines deploying to GKE: secure CI/CD pipelines are part of the security perimeter; a compromised pipeline can bypass every runtime control

For short-lived learning clusters or sandboxes with no sensitive data and no connection to production resources, a lighter setup may be acceptable. Even then, it is worth enabling Workload Identity and using a scoped node service account. The habits carry directly into production work.

Core security layers for GKE

Node security: Shielded GKE Nodes and Container-Optimized OS#

The security of a GKE cluster starts at the machine level.

Container-Optimized OS (COS) is a minimal Linux distribution maintained by Google for running containers. It ships with no package manager, no SSH server by default, and a read-only root filesystem. This reduces the attack surface considerably compared to a general-purpose Linux distribution. COS is the default node image for GKE and should be your first choice unless you have a specific compatibility requirement.

Shielded GKE Nodes add hardware-rooted security features on top of COS:

• Secure Boot verifies that the node’s bootloader, kernel, and kernel modules have not been tampered with. If verification fails, the node refuses to boot.
• vTPM (Virtual Trusted Platform Module) is a virtualised cryptographic chip that holds boot measurements, enabling attestation of the node’s boot state.
• Integrity Monitoring compares runtime boot measurements against a known-good baseline and alerts if a deviation is detected.

Enable Shielded Nodes at cluster creation:

gcloud container clusters create my-cluster \
  --region=europe-west2 \
  --shielded-secure-boot \
  --shielded-integrity-monitoring \
  --enable-shielded-nodes

Workload identity and IAM#

Pods often need to call Google Cloud APIs: reading from Cloud Storage, writing to Pub/Sub, accessing Secret Manager. The only production-grade way to grant this access in GKE is Workload Identity.

Workload Identity binds a Kubernetes ServiceAccount to a Google Cloud IAM service account. Pods receive short-lived, automatically rotated tokens. No key file ever touches disk or enters a container.

Mounting a service account key file as a Kubernetes Secret is the alternative many teams use initially. It is the wrong approach in production. Key files do not expire, are difficult to rotate across many pods, and represent a permanent credential that can be used from anywhere if exfiltrated. See Why service account keys are dangerous and Service account keys explained for a detailed breakdown of the risks.

Enable Workload Identity at cluster creation:

gcloud container clusters create my-cluster \
  --region=europe-west2 \
  --workload-pool=PROJECT_ID.svc.id.goog \
  --workload-metadata=GKE_METADATA

Node service account minimisation. GKE nodes run under a Google Cloud service account. The default is the Compute Engine default service account, which has the primitive Editor role. This creates a very large blast radius if any pod bypasses Workload Identity and calls the metadata server directly. Create a dedicated, narrowly scoped node service account instead:

gcloud iam service-accounts create gke-node-sa \
  --display-name="GKE Node Service Account"

for role in roles/logging.logWriter roles/monitoring.metricWriter \
            roles/monitoring.viewer roles/artifactregistry.reader; do
  gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:gke-node-sa@PROJECT_ID.iam.gserviceaccount.com" \
    --role="$role"
done

gcloud container clusters create my-cluster \
  --service-account=gke-node-sa@PROJECT_ID.iam.gserviceaccount.com

These four roles are the minimum required for a GKE node to function. Anything beyond them is unnecessary privilege. See IAM Roles Explained and Least Privilege in GCP for the broader principle.

Kubernetes RBAC#

Kubernetes Role-Based Access Control (RBAC) governs who can perform which operations on which resources inside the cluster. In GKE, RBAC integrates with Google Cloud IAM: when a user authenticates with gcloud and runs kubectl, their Google identity is matched against RBAC policies.

Role vs ClusterRole. A Role grants permissions within a single namespace. A ClusterRole grants permissions across all namespaces or for cluster-scoped resources such as nodes and persistent volumes.

Creating a Role that allows reading Pods and Services in the production namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["pods", "services"]
    verbs: ["get", "list", "watch"]

Binding this Role to a user:

kubectl create rolebinding pod-reader-binding \
  --role=pod-reader \
  --user=alice@example.com \
  --namespace=production

Cluster-wide roles follow the same pattern:

kubectl create clusterrole node-reader \
  --verb=get,list,watch \
  --resource=nodes

kubectl create clusterrolebinding node-reader-binding \
  --clusterrole=node-reader \
  --user=ops-team@example.com

GKE also integrates with Google Groups for RBAC, allowing you to bind roles to a Google Workspace group rather than individual email addresses. This is much easier to manage as teams change.

To audit what permissions an identity currently has:

kubectl auth can-i --list --as=alice@example.com -n production

Network controls#

NetworkPolicy controls traffic between pods at layer 3/4. Without it, all pods in your cluster can reach all other pods by default. Enable NetworkPolicy support at cluster creation with --enable-network-policy, then apply a default deny-all ingress policy per namespace and explicitly allow only the required traffic paths.

A default deny-all ingress policy for a namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress

See the GKE Networking Model page for detailed NetworkPolicy examples including egress controls and pod selector patterns.

Private clusters give nodes only RFC 1918 private IP addresses, removing them from direct internet exposure:

gcloud container clusters create my-cluster \
  --enable-private-nodes \
  --master-ipv4-cidr=172.16.0.0/28 \
  --enable-private-endpoint

Authorised Networks restrict which source IP ranges can reach the control plane’s Kubernetes API endpoint:

gcloud container clusters create my-cluster \
  --enable-master-authorized-networks \
  --master-authorized-networks=203.0.113.0/24,198.51.100.0/24

You can update authorised networks on an existing cluster without recreating it:

gcloud container clusters update my-cluster \
  --region=europe-west2 \
  --enable-master-authorized-networks \
  --master-authorized-networks=203.0.113.0/24

Image and supply chain security#

A cluster is only as secure as the container images running in it. Two controls protect the image supply chain.

Artifact Registry vulnerability scanning automatically scans images pushed to Artifact Registry for known CVEs. Results appear in the Cloud Console or via the Container Analysis API. Integrate this into your CI/CD pipeline to fail builds when critical or high vulnerabilities are detected. See Artifact Registry best practices for scanning configuration and image lifecycle management.

Binary Authorization is a deploy-time policy control. It requires that container images have been cryptographically attested, typically by your CI/CD pipeline after passing defined checks, before they can be deployed to GKE. Unsigned images are blocked at deploy time.

Enable Binary Authorization on a cluster:

gcloud container clusters create my-cluster \
  --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

A typical Binary Authorization workflow:

1. CI pipeline builds and pushes image to Artifact Registry.
2. Pipeline runs security scans. If scans pass, a Cloud KMS-based attestor signs the image digest.
3. A CD pipeline deploys to GKE.
4. GKE checks the Binary Authorization policy, verifies the attestation, and either allows or blocks the deployment.

Secrets and encryption#

Kubernetes Secrets store sensitive values: database passwords, API keys, TLS certificates. By default, these values are stored in etcd base64-encoded but not encrypted. Anyone with etcd access, or with sufficient RBAC permissions to read Secrets, can retrieve plaintext values.

GKE supports application-layer secret encryption using Cloud KMS. When enabled, the Kubernetes API server encrypts Secret values with a Cloud KMS key before writing them to etcd, and decrypts them on retrieval.

Enable application-layer encryption at cluster creation:

gcloud container clusters create my-cluster \
  --database-encryption-key=projects/PROJECT_ID/locations/europe-west2/keyRings/my-keyring/cryptoKeys/my-key

For the highest assurance, use Secret Manager instead of Kubernetes Secrets entirely. With Secret Manager, secrets never enter etcd. Pods retrieve secrets at runtime via the Secret Manager API or the Secret Manager CSI driver, which mounts secrets as files or environment variables. See Managing Secrets in Kubernetes for the full comparison between Kubernetes Secrets, KMS-encrypted Secrets, and Secret Manager.

Logging, monitoring, and audit visibility#

Security controls reduce the chance of a breach. Logging and monitoring give you the ability to detect one when it happens, and to prove what occurred after the fact.

Cloud Audit Logs record every administrative and data access API call against the cluster: who created or deleted what, which secrets were read, which RBAC bindings changed. Enable Data Access audit logs for the Kubernetes API in addition to the default Admin Activity logs.

Logging in Kubernetes captures workload output including application logs, crash events, and container stderr, and routes it to Cloud Logging for structured querying and alerting.

Monitoring GKE clusters surfaces resource usage, node health, and deployment status in Cloud Monitoring dashboards.

Security Command Center surfaces GKE-specific findings automatically: misconfigured RBAC bindings, overprivileged workloads, open firewall rules that expose cluster nodes, and known vulnerabilities in running images.

Detecting suspicious activity with logs explains how to create log-based alerts for events like unexpected exec commands into pods, unauthorised API calls, or changes to RBAC bindings.

GKE security vs related controls

These controls are often confused because they all relate to GKE security. They are complementary, not interchangeable.

Practical GKE security checklist

Use this as a starting point for any production cluster review. Work through the layers in order, starting with identity and nodes, then moving to network, image supply chain, and secrets.

• Create a dedicated, minimally scoped node service account (not the Compute Engine default)
• Enable Workload Identity (--workload-pool) on all clusters
• Enable Shielded GKE Nodes: Secure Boot, vTPM, Integrity Monitoring
• Use Container-Optimized OS as the node image
• Review all RBAC bindings; remove cluster-admin grants that are not break-glass
• Apply default deny-all ingress NetworkPolicies per namespace; explicitly allow required paths
• Enable --enable-master-authorized-networks or use a private endpoint
• Use private clusters for production workloads that should not be internet-reachable
• Scan images in Artifact Registry; fail CI builds on critical CVEs
• Enforce Binary Authorization in production; use image digests, not mutable tags
• Enable application-layer secret encryption with Cloud KMS, or migrate to Secret Manager
• Enable Data Access audit logs for the Kubernetes API
• Set up Cloud Monitoring dashboards and alerts for the cluster
• Review Security Command Center findings for GKE-specific recommendations