Why GKE security requires more than Google's defaults
GKE operates under a shared responsibility model. Google secures the physical infrastructure, hypervisor layer, and control plane components through encryption, network segmentation, and regular security audits, running them on single-tenant Compute Engine instances operated by Google for only one customer.
You are responsible for everything running inside your clusters: workload configurations, identity permissions, network policies, secrets management, and container image security. Most GKE security incidents trace back to customer-side misconfigurations rather than Google infrastructure vulnerabilities.
Actionable Kubernetes Security Best Practices [Cheat Sheet]
We’ve put together a cheat sheet of some advanced steps you can take to safeguard your Kubernetes clusters.
7 GKE security best practices
GKE provides configurable security settings to help you meet your side of this responsibility. These include Workload Identity Federation for secure service authentication, Shielded GKE Nodes for node integrity verification, network policies for traffic segmentation, and Binary Authorization for image verification. The practices below show you how to configure each effectively.
1. Harden cluster infrastructure and nodes
Cluster hardening protects the control plane and worker nodes from unauthorized access and tampering. The following practices address node image selection, control plane access restrictions, and compliance validation.
Keep Kubernetes versions current: GKE automatically upgrades control plane components, but Standard mode clusters require you to manually upgrade worker nodes when new versions or security patches are released. Establish a regular upgrade cadence to avoid running vulnerable versions. Autopilot clusters handle both control plane and node upgrades automatically.
By default, GKE exposes the control plane components through a public IP. Exposed components include the API server, controller manager, the etcd database, and the scheduler. Here is a sample command that can be used to create a cluster that restricts access to the control plane to a set of authorized networks:
gcloud container clusters create-auto CLUSTER_NAME \
--enable-master-authorized-networks \
--master-authorized-networks CIDR1,CIDR2,...
gcloud container clusters create-auto CLUSTER\_NAME \ --enable-master-authorized-networks \ --master-authorized-networks CIDR1,CIDR2,...Enable Shielded GKE Nodes: Shielded Nodes use hardened VMs with Secure Boot and virtual Trusted Platform Module (vTPM) to protect against rootkits and bootkits. vTPM provides cryptographic attestation of node integrity, allowing you to verify that nodes have not been tampered with before they join the cluster. Without Shielded Nodes, attackers who exploit pod vulnerabilities can more easily persist on host nodes.
To create a GKE cluster with Shielded VMs, use this command:
gcloud container clusters create CLUSTER_NAME \
--enable-shielded-nodes
gcloud container clusters create CLUSTER\_NAME \ --enable-shielded-nodes
Use a custom IAM service account for nodes: By default, GKE nodes use the Compute Engine default service account, which is granted the Editor role on the project—far more access than nodes actually need to function. If a node is compromised, that over-permission becomes a direct path to broader cloud resources.
Create a dedicated service account for your node pool with only the permissions GKE requires (logging, monitoring, and artifact pulls), and assign it at cluster or node-pool creation:
gcloud container clusters create CLUSTER_NAME \ --service-account=NODE_SA_EMAILConsider Autopilot for enforced security defaults: Autopilot mode enables Shielded Nodes, Workload Identity Federation, automatic upgrades, and strict network policies by default. These settings cannot be disabled, which eliminates configuration drift but limits customization. Choose Standard mode if you need custom node images, specific machine types, or security contexts that Autopilot restricts.
Validate against CIS Benchmarks: The Center for Internet Security publishes the CIS Google Kubernetes Engine Benchmark, a consensus-driven baseline for configuration controls covering everything from control-plane access to pod security standards. It's the de facto compliance reference for GKE and is required or recommended by frameworks like SOC 2, PCI DSS, and HIPAA.
Treat the CIS Benchmark as a starting point. Automated scanning tools, including kube-bench for self-managed assessment and most cloud security posture management (CSPM) platforms, can continuously evaluate your clusters against the benchmark and surface drift over time. A passing score confirms that your configuration matches the baseline; it does not confirm that your clusters are secure against active threats, which requires runtime detection and attack-path analysis in addition to posture controls.
2. Isolate networks and restrict traffic
GKE network security operates at multiple layers: VPC Service Controls prevent data exfiltration at the project boundary, private clusters restrict control plane access, private nodes isolate workloads from the internet, and NetworkPolicies govern pod-to-pod traffic. Missing any layer creates exposure.
Use private nodes to isolate from the internet: Private nodes are GKE worker nodes with no external IP address, so they cannot be reached directly from the public internet. This significantly reduces the attack surface, since attackers cannot probe or exploit node-level services without first compromising something inside your cloud environment. Combine private nodes with private clusters (which restrict control plane access to authorized networks) for full isolation of both the workload and management layers.
Together, they isolate both the workloads and the management layer from the open internet:
gcloud container clusters create CLUSTER_NAME \
--enable-private-nodes \
--master-ipv4-cidr=172.16.0.0/28Restrict pod-to-pod traffic with NetworkPolicies: By default, all pods in a GKE cluster can communicate freely. This increases lateral movement risk if an attacker compromises a single pod. NetworkPolicies let you define ingress and egress rules based on pod labels, namespaces, or IP blocks. Start with a default-deny policy, then explicitly allow only the traffic your applications require.
Network policies use labels to manage the ingress and egress traffic from pods in the cluster. By creating network policies, you gain granular control over which pods can send or receive traffic from various sources, like other pods, namespaces, or IP blocks.
You can also create implicit deny rules for egress and ingress traffic, ensuring that only explicitly authorized traffic is allowed between pods. Keep in mind that a default deny-all egress policy also blocks DNS traffic, so you must add a separate NetworkPolicy if your workloads need DNS resolution.
Here is a sample network policy that allows ingress traffic only from pods with a specific label:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: sample-policy
spec:
policyTypes:
- Ingress
podSelector:
matchLabels:
app: test
ingress:
- from:
- podSelector:
matchLabels:
app: devUse VPC Service Controls: VPC Service Controls create a service perimeter around your Google Cloud resources, preventing data exfiltration from sensitive services like Cloud Storage and BigQuery, even if credentials are compromised. For GKE clusters handling regulated data, configure a service perimeter around the project and explicitly allow the APIs your workloads need to access. This adds a project-boundary defense that catches what IAM and NetworkPolicies cannot.
Filter load-balanced communication: When configuring external access for your GKE services with a load balancer, consider filtering incoming traffic for added security. Filters can be implemented at the node level using kube-proxy, allowing you to specify which IP addresses are allowed to access the external load balancer public IP.
3. Secure workload identity and permissions
Workload Identity Federation is GKE's recommended method for authenticating workloads to Google Cloud services. It eliminates the need for service account keys, which are the most common credential leak vector in GKE environments. Workload Identity Federation links Kubernetes service accounts directly to Google Cloud IAM service accounts, providing a clear identity for each application without exportable credentials and returning an access token with a default lifetime of 1 hour.
Enable Workload Identity Federation at cluster creation: Use the --workload-pool flag when creating your cluster, then annotate Kubernetes service accounts to bind them to Google Cloud IAM service accounts. Apply least privilege at the IAM layer—not just RBAC—by scoping each workload's IAM policy to the specific Google Cloud APIs and resources it actually uses.
Use conditional role bindings for time-bound access: For sensitive operations, apply IAM conditions that restrict access to specific time windows or request attributes, limiting the blast radius if credentials are compromised.
You can use conditional role bindings to further refine access permissions. For example, you can use the code below to create time-bound access to a cloud resource:
{
"bindings": [
{
"members": [
"user:project-owner@example.com"
],
"role": "roles/owner"
},
{
"members": [
"user:travis@example.com"
],
"role": "roles/iam.securityReviewer",
"condition": {
"title": "Expires_2026",
"description": "Expires at noon on 2026-12-31",
"expression":
"request.time < timestamp('2026-12-31T12:00:00Z')"
}
}
],
"etag": "BwWPmjvelug=",
"version": 3
}Enforce least privilege with Kubernetes RBAC: Create roles that grant only the specific verbs (get, list, watch, create, update, delete) needed for each service account, scoped to specific resources and namespaces. Avoid cluster-wide roles unless absolutely necessary.
Disable legacy ABAC: Ensure the legacy attribute-based access control configuration is disabled so that all access decisions flow through Kubernetes RBAC and Google Cloud IAM. ABAC lacks the granularity needed for production security.
4. Protect secrets with external storage and encryption
Secrets stored in GKE clusters should be encrypted at the application layer and, when possible, managed entirely outside the cluster. GKE encrypts all data at rest by default, but application-layer encryption with Cloud KMS gives you control over key rotation and access policies.
To enable application-layer encryption, create a Cloud KMS key and grant your GKE service account access to it:
gcloud container clusters update CLUSTER_NAME \
--region=COMPUTE_REGION \
--database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
--project=CLUSTER_PROJECT_IDIn addition to native KMS, you can use open-source key management services, such as HashiCorp Vault, to protect secrets in GKE clusters.
5. Isolate workloads at runtime
Isolating each workload from others is an essential best practice for limiting your attack surface. GKE offers various mechanisms for workload isolation.
Leverage GKE Sandbox: You can isolate untrusted workloads in a private cluster using GKE Sandbox. GKE Sandbox uses open-source gVisor technology on the backend to protect against common risks, such as container escapes and Dirty Cow privilege escalation attacks.
Use this command to create a new node pool in a GKE cluster with GKE Sandbox enabled:
gcloud container node-pools create NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--machine-type=MACHINE_TYPE \
--image-type=cos_containerd \
--sandbox type=gvisor
gcloud container node-pools create NODE\_POOL\_NAME \ --cluster=CLUSTER\_NAME \ --machine-type=MACHINE\_TYPE \ --image-type=cos\_containerd \ --sandbox type=gvisor🚨 Google Kubernetes Engine (GKE) clusters are being targeted faster than ever
The Wiz Kubernetes Security Report 2025 found that newly deployed GKE clusters faced malicious probing within just 1 hour and 15 minutes—a significant reduction from last year’s 2-hour window.
Download PDF
Restrict container process privileges: In addition to using GKE Autopilot to implement built-in security guardrails, you can also use features like security contexts and Docker AppArmor security policies to limit the privileges of processes running in containers. With security contexts, you can control aspects such as privilege escalation, Linux capabilities, the "run as" user, and group access. The Docker AppArmor security policies enabled by default in GKE clusters prevent containers from directly manipulating sensitive files or file systems in the cluster.
6. Secure the container supply chain
To shift left in your software supply chain, ensure the security and integrity of container images deployed to GKE clusters. Implementing an image signing and verification process is a critical aspect of this process, and Binary Authorization is the way to achieve it.
GKE supports image signing and verification through integration with Binary Authorization and Artifact Registry. You can also use any other container image registry service. With Binary Authorization enabled, you can attest that a container image is signed with a private key, confirming that it was created using a specified build process.
These digital signatures are verified during deployment to ensure that only trusted images are deployed in your cluster, though specific image paths that contain resources required for GKE to start are exempt by default. Use the following command to create a GKE cluster with Binary Authorization enabled:
gcloud container clusters create \
--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
--zone us-central1-a \
test-cluster
gcloud container clusters create \ --binauthz-evaluation-mode=PROJECT\_SINGLETON\_POLICY\_ENFORCE \ --zone us-central1-a \ test-cluster7. Enable comprehensive audit logging
Audit logs record every API request to your GKE cluster, creating an evidence trail for security investigations and compliance audits. When a breach occurs, audit logs let you reconstruct exactly what an attacker accessed and modified. GKE provides two log types you should review regularly:
Admin activity logs monitor administrative actions on your clusters, including the creation and deletion of namespaces, deployments, and pods. These logs reveal who performed the actions and the resources involved.
Data access logs provide information on how users interact with Kubernetes APIs to access or modify data within clusters. This information includes data about who is reading or writing pod configuration files, secrets, and other cluster resources.
How Wiz strengthens GKE security beyond native controls
The practices above cover the customer side of GKE's shared responsibility model, but configuration is only half the battle. Native GKE controls don't correlate risks across clusters, cloud infrastructure, and identities, and passing a CIS benchmark audit doesn't mean your clusters are secure against active threats. Wiz connects posture management with runtime threat detection, surfacing attack paths that span containers, nodes, and cloud resources.
GKE is increasingly where AI workloads live—from model-serving infrastructure to training pipelines and inference endpoints. Wiz extends the same agentless visibility to these components:
Discovering self-hosted models and agents on GKE clusters
Mapping their service accounts and identities
Flagging exposed inference endpoints
Tracing training data flows into production
An over-permissioned model-serving pod with access to sensitive training data shows up as one correlated attack path, not three disconnected alerts across Kubernetes, IAM, and storage. That kind of correlated view is what separates secure GKE clusters from compliant ones—across nodes, RBAC, supply chain, and AI workloads alike.
Get a demo to see how Wiz transforms GKE security.
