GKE Security

Google Kubernetes Engine – GKE Security provides multiple layers of security to secure workloads including the contents of the container image, the container runtime, the cluster network, and access to the cluster API server.

Authentication and Authorization

• Kubernetes supports two types of authentication:
  • User accounts are accounts that are known to Kubernetes but are not managed by Kubernetes
  • Service accounts are accounts that are created and managed by Kubernetes but can only be used by Kubernetes-created entities, such as pods.
• In a GKE cluster, Kubernetes user accounts are managed by Google Cloud and can be of the following type
  • Google Account
  • Google Cloud service account
• Once authenticated, these identities need to be authorized to create, read, update or delete Kubernetes resources.
• Kubernetes service accounts and Google Cloud service accounts are different entities.
  • Kubernetes service accounts are part of the cluster in which they are defined and are typically used within that cluster.
  • Google Cloud service accounts are part of a Google Cloud project, and can easily be granted permissions both within clusters and to Google Cloud project clusters themselves, as well as to any Google Cloud resource using IAM.

Control Plane Security

• In GKE, the Kubernetes control plane components are managed and maintained by Google.
• Control plane components host the software that runs the Kubernetes control plane, including the API server, scheduler, controller manager, and the etcd database where the Kubernetes configuration is persisted.
• By default, the control plane components use a public IP address.
• Kubernetes API server can be protected by using authorized networks, and private clusters, which allow assigning a private IP address to the control plane and disable access on the public IP address.
• Control plane can also be secured by doing credential rotation on a regular basis. When credential rotation is initiated, the SSL certificates and cluster certificate authority are rotated. This process is automated by GKE and also ensures that your control plane IP address rotates.
• GKE encrypts etcd data at rest by default. Application-layer secrets encryption provides an additional layer of security by encrypting Kubernetes Secrets in etcd using a Cloud KMS key that you manage.

Node Security

Container-Optimized OS

• GKE nodes, by default, use Google’s Container-Optimized OS (cos_containerd) as the operating system on which to run Kubernetes and its components.
• Container-Optimized OS features include
  • Locked-down firewall
  • Read-only filesystem where possible
  • Limited user accounts and disabled root login
• GKE uses containerd as the container runtime for all new clusters and node pools.

Shielded GKE Nodes

• Shielded GKE Nodes provide verifiable node identity and integrity by using Secure Boot, vTPM, and integrity monitoring.
• Shielded GKE Nodes are enabled by default and cannot be overridden on new clusters.
• They protect against boot-level and kernel-level malware or rootkits that could persist beyond an infected OS.

Node upgrades

• GKE recommends upgrading nodes on a regular basis to patch the OS for security issues in the container runtime, Kubernetes itself, or the node operating system.
• GKE supports automatic as well as manual upgrades.
• GKE automatically applies security patches to nodes when available, adhering to configured maintenance schedules.

Protecting nodes from untrusted workloads

• GKE Sandbox can be enabled on the cluster to isolate untrusted workloads in sandboxes on the node if the clusters run unknown or untrusted workloads.
• GKE Sandbox is built using gVisor, an open-source container runtime that provides a specialized guest kernel for each container, intercepting system calls between the application and the host kernel.
• GKE Agent Sandbox (2025) is an evolution of GKE Sandbox optimized for AI agent workloads, providing kernel-level isolation for untrusted LLM-generated code execution with sub-second latency and the ability to orchestrate hundreds of sandboxes per second.

Seccomp Profiles

• GKE applies the default containerd seccomp profile to provide baseline syscall filtering while maintaining workload compatibility.
• Autopilot clusters enforce Pod Security Standards at the Baseline level by default, preventing known privilege escalation pathways.

Securing instance metadata

• GKE nodes run as Compute Engine instances and have access to instance metadata by default, which a Pod running on the node does not necessarily need.
• Workload Identity Federation for GKE replaces the need to use Metadata Concealment. When Workload Identity Federation is enabled, it blocks access to the node’s metadata server from workloads.
• Legacy metadata APIs are disabled by default on GKE versions 1.12 and newer.

Network Security

• Network Policies help cluster administrators and users lock down the ingress and egress connections created to and from the Pods in a namespace.
• GKE has two mutually exclusive network policy plugins:
  • GKE Dataplane V2 (based on Cilium/eBPF) – the recommended plugin for all clusters and the default for Autopilot clusters. Provides enhanced visibility, performance, and advanced policy features.
  • Calico (iptables-based) – available only in Standard clusters.
• FQDN Network Policies (GKE Dataplane V2) allow controlling Pod egress traffic based on fully qualified domain names rather than IP addresses.
• mTLS for Pod-to-Pod communication can be enabled using Cloud Service Mesh (previously known as Istio on GKE/Anthos Service Mesh).

Giving Pods Access to Google Cloud Resources

Workload Identity Federation for GKE (recommended)

• Workload Identity Federation for GKE (previously called Workload Identity) is the simplest and most secure way to authorize Pods to access Google Cloud resources.
• Pods authenticate with short-lived federated tokens tied to their Kubernetes ServiceAccount — no long-lived credentials are stored in the container.
• Kubernetes entities (clusters, service accounts) can now be addressed directly as IAM principals.
• Workload Identity Federation for GKE replaces the need for Metadata Concealment, and the two approaches are incompatible.
• Fleet Workload Identity Federation extends this capability across an entire fleet, including clusters outside Google Cloud and across multiple projects.

Node Service Account

• Pods can authenticate to Google Cloud using the Kubernetes cluster’s service account credentials from metadata.
• Node Service Account credentials can be reached by any Pod running in the cluster if Workload Identity Federation is not enabled.
• It is recommended to create and configure a custom service account that has the minimum IAM roles required by all the Pods running in the cluster.

Service Account JSON key

• Applications can access Google Cloud resources by using the service account’s key.
• This approach is NOT recommended because of the difficulty of securely managing account keys.
• A JSON service account key can be created and then mounted into the Pod using a Kubernetes Secret.
• Workload Identity Federation for GKE eliminates the need for key files entirely and is the preferred alternative.

Secrets Management

• Application-layer Secrets Encryption encrypts Kubernetes Secrets stored in etcd using a Cloud KMS key that you manage, providing an additional layer of protection beyond default GKE encryption.
• Secret Manager add-on for GKE allows Pods to directly access secrets stored in Google Cloud Secret Manager via the Secrets Store CSI Driver, without requiring custom code.
• Secret Manager add-on supports auto-rotation and syncing secrets as Kubernetes Secret objects.

Binary Authorization

• Binary Authorization helps ensure that internal processes that safeguard the quality and integrity of the software have successfully completed before an application is deployed to the production environment.
• Binary Authorization works with images deployed to GKE from Artifact Registry (Container Registry was shut down on March 18, 2025).
• Binary Authorization provides:
  • A policy model that lets you describe the constraints under which images can be deployed
  • An attestation model that lets you define trusted authorities who can attest or verify that required processes have completed before deployment
  • A deploy-time enforcer that prevents images that violate the policy from being deployed
• Continuous Validation (CV) monitors running Pods to ensure their container images continue to conform to Binary Authorization check-based platform policies, including:
  • Image freshness checks
  • Simple signing attestation checks
  • Sigstore signature verification
  • SLSA provenance checks (requires Cloud Build)
  • Vulnerability checks

GKE Autopilot Security

• Autopilot mode clusters have a stricter default security posture than Standard mode clusters.
• GKE Autopilot automatically configures nodes, node pools, and in-cluster policy according to security best practices.
• Key Autopilot security defaults:
  • Workload Identity Federation for GKE is always enabled
  • Shielded GKE Nodes are enabled
  • GKE Dataplane V2 is the default network plugin
  • Pod Security Standards are enforced at the Baseline level
  • Privileged containers and host namespace access are restricted
  • Container-Optimized OS with containerd is the only supported node image

GKE Security Posture

• The GKE security posture dashboard helps proactively identify and address security vulnerabilities in GKE clusters.
• Features include Kubernetes security configuration scanning (misconfiguration detection) and workload vulnerability scanning.
• Note: As of January 2025, several GKE security posture capabilities have been deprecated:
  • GKE threat detection (deprecated Jan 28, 2025, shut down March 31, 2025)
  • GKE Compliance dashboard (deprecated Jan 28, 2025)
  • Workload vulnerability scanning in GKE Standard edition has been removed; it requires GKE Enterprise edition
• For comprehensive threat detection and vulnerability management, Google recommends using Security Command Center.

GCP Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. You are building a product on top of Google Kubernetes Engine (GKE). You have a single GKE cluster. For each of your customers, a Pod is running in that cluster, and your customers can run arbitrary code inside their Pod. You want to maximize the isolation between your customers’ Pods. What should you do?
   1. Use Binary Authorization and whitelist only the container images used by your customers’ Pods.
   2. Use the Container Analysis API to detect vulnerabilities in the containers used by your customers’ Pods.
   3. Create a GKE node pool with a sandbox type configured to gVisor. Add the parameter runtimeClassName: gvisor to the specification of your customers’ Pods.
   4. Use the cos_containerd image for your GKE nodes. Add a nodeSelector with the value cloud.google.com/gke-os-distribution: cos_containerd to the specification of your customers’ Pods.
2. Your organization runs workloads on GKE and wants to ensure that Pods can only access Google Cloud APIs using short-lived credentials without managing service account keys. What should you configure?
   1. Create a Google Cloud service account key and store it as a Kubernetes Secret.
   2. Enable Workload Identity Federation for GKE and bind the Kubernetes ServiceAccount to a Google Cloud service account as an IAM principal.
   3. Use the node’s default service account credentials with metadata concealment enabled.
   4. Download a service account key and mount it as a volume in the Pod.
3. You need to control egress traffic from Pods in your GKE cluster to specific external services by domain name. Which feature should you use?
   1. Standard Kubernetes NetworkPolicy with IP address blocks.
   2. Cloud Armor policies applied to the cluster.
   3. FQDN Network Policies with GKE Dataplane V2 enabled.
   4. VPC firewall rules targeting the node IP addresses.
4. Your company needs to ensure that only container images that have been verified and attested by your CI/CD pipeline can be deployed to your GKE production cluster. Additionally, you want ongoing monitoring of running workloads. What should you implement?
   1. Use Artifact Registry vulnerability scanning only.
   2. Configure Pod Security Standards at the Restricted level.
   3. Enable Binary Authorization with attestation policies and Continuous Validation (CV) for runtime monitoring.
   4. Use GKE Sandbox to isolate all production workloads.
5. You want your GKE cluster to have the strongest default security configuration with minimal manual setup. Which cluster mode should you use?
   1. Standard mode with all security features manually enabled.
   2. Autopilot mode, which enforces security best practices by default including Workload Identity Federation, Shielded Nodes, and Pod Security Standards.
   3. Standard mode with Container-Optimized OS selected.
   4. Standard mode with Shielded GKE Nodes enabled.

References

• Google Kubernetes Engine – Security Overview
• Workload Identity Federation for GKE
• Best practices for hardening your cluster’s security
• GKE Autopilot security measures
• Binary Authorization – Continuous Validation overview
• GKE Dataplane V2
• GKE Agent Sandbox