GKE Security Overview

Google Kubernetes Engine (GKE) provides many ways to help secure your workloads. Protecting workloads in GKE involves many layers of the stack, including container images, the container runtime, the cluster network, and access to the cluster API server.

Security Layers

It's best to take a layered approach to protecting your clusters and workloads, applying the principle of least privilege to all levels.

Authentication and Authorization

Account Types

Type	Managed By	Use Case
User Accounts	Google Cloud	Human users (Google Accounts)
Google Cloud Service Accounts	Google Cloud	Cross-project access, Google Cloud resource access
Kubernetes Service Accounts	Kubernetes	Pod-level access within cluster

Authorization Methods

Method	Scope	Description
IAM	Project/Organization	Google Cloud resource access
RBAC	Cluster/Namespace	Kubernetes resource access

Best Practice: Disable legacy Attribute Based Access Control (ABAC) so that Kubernetes RBAC and IAM are the sources of truth.

Control Plane Security

Control Plane Protection Methods

Method	Description
DNS-based Endpoint	Use IAM and VPC Service Controls for identity and network-aware policies (recommended)
Authorized Networks	Restrict control plane access to specific IP ranges
Credential Rotation	Rotate SSL certificates and cluster CA regularly

Node Security

Container-Optimized OS Features

Feature	Description
Locked-down firewall	Minimal network exposure
Read-only filesystem	Prevents unauthorized modifications
Limited user accounts	Disabled root login

Node Protection

Feature	Description	Use Case
Automatic Upgrades	Patch OS regularly	Security updates
GKE Sandbox	Isolate untrusted workloads	Multi-tenant, SaaS, security research
Workload Identity	Lock down instance metadata	Protect node service account keys

Network Security

Network Policies

By default, all Pods can communicate with each other. Network policies allow you to:

Best Practice: Apply default deny policies for both ingress and egress of every Pod, then explicitly allow required traffic.

Load Balancer Filtering

# Example: Restrict access by source IP
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  loadBalancerSourceRanges:
    - 10.0.0.0/8
    - 192.168.1.0/24
  ports:
    - port: 80
      targetPort: 8080

Workload Security

Security Context Options

Setting	Description
runAsUser/runAsGroup	User and group to run as
capabilities	Available Linux capabilities
allowPrivilegeEscalation	Control privilege escalation
readOnlyRootFilesystem	Prevent filesystem modifications

Pod Security Standards

Level	Description
Privileged	Unrestricted
Baseline	Minimally restrictive, prevents known privilege escalations
Restricted	Heavily restricted, following hardening best practices

Accessing Google Cloud Resources

Method	Security	Recommendation
Workload Identity Federation	Most secure	Recommended
Node Service Account	Less secure	Not compatible with GKE Sandbox
Service Account JSON Key	Least secure	Strongly discouraged

Binary Authorization

Binary Authorization ensures:

• Internal safeguard processes completed before deployment
• Container images conform to policies with Continuous Validation (CV)

Audit Logging

Built-in Security Measures

Autopilot Security

Autopilot clusters apply security settings based on best practices:

Feature	Status
Container-Optimized OS	Enabled
Workload Identity	Always enabled
Shielded GKE Nodes	Enabled
Security hardening	Pre-configured

Standard Cluster Security

Restriction	Description
System workload ServiceAccount	Cannot be updated
cluster-admin binding	Cannot bind to anonymous/unauthenticated groups

Security Checklist

Layer	Key Actions
Authentication	Use IAM, disable legacy ABAC
Control Plane	Enable authorized networks, use DNS endpoint
Nodes	Use Container-Optimized OS, enable Workload Identity
Network	Apply network policies, use internal load balancers
Workloads	Use security contexts, enable Binary Authorization
Audit	Enable audit logging, set up alerting

---

Last updated: December 2025