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 the contents of your container image, the container runtime, the cluster network, and access to the cluster API server.



Authentication and authorization

Kubernetes supports two types of authentication:


In a GKE cluster, Kubernetes user accounts are managed by Google Cloud, and may be one of the following two types:

  1. Google Account
  2. Google Cloud service account


Despite the similar names, 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. By contrast, 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 Identity and Access Management (IAM). This makes Google Cloud service accounts more powerful than Kubernetes service accounts; in order to follow the security principle of least privilege, you should consider using Google Cloud service accounts only when their capabilities are required.

To configure more granular access to Kubernetes resources at the cluster level or within Kubernetes namespaces, you use Role-Based Access Control (RBAC). RBAC allows you to create detailed policies that define which operations and resources you allow users and service accounts to access. With RBAC, you can control access for Google Accounts, Google Cloud service accounts, and Kubernetes service accounts. To further simplify and streamline your authentication and authorization strategy for GKE, you should ensure that the legacy Attribute Based Access Control is disabled so that Kubernetes RBAC and IAM are the sources of truth.

For more information:

Control plane security

In GKE, the Kubernetes control plane components are managed and maintained by Google. The control plane components host the software that runs the Kubernetes control plane, including the API server, scheduler, controller manager and the etcd database where your Kubernetes configuration is persisted.

By default, the control plane components use a public IP address. You can protect the Kubernetes API server by using authorized networks, and private clusters, which allow you to assign a private IP address to the control plane and disable access on the public IP address.

You can handle cluster authentication in Google Kubernetes Engine by using IAM as the identity provider. For information on authentication, see Authenticating to the Kubernetes API server.

Another way to help secure your control plane is to ensure that you are 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.

For more information:

Node security

GKE deploys your workloads on Compute Engine instances running in your Google Cloud project. These instances are attached to your GKE cluster as nodes. The following sections show you how leverage the node-level security features available to you in Google Cloud.

Container-Optimized OS

By default, GKE nodes use Google's Container-Optimized OS as the operating system on which to run Kubernetes and its components. Container-Optimized OS implements several advanced features for enhancing the security of GKE clusters, including:

  • Locked-down firewall
  • Read-only filesystem where possible
  • Limited user accounts and disabled root login

Node upgrades


You can manually upgrade the nodes in your cluster, but GKE also allows you to enable automatic upgrades.

Protecting nodes from untrusted workloads

For clusters that run unknown or untrusted workloads, a good practice is to protect the operating system on the node from the untrusted workload running in a Pod.

For example, multi-tenant clusters such as software-as-a-service (SaaS) providers often execute unknown code submitted by their users. Security research is another application where workloads may need stronger isolation than nodes provide by default.

You can enable GKE Sandbox on your cluster to isolate untrusted workloads in sandboxes on the node. GKE Sandbox is built using gVisor, an open source project.

Securing instance metadata


Network security


Limiting Pod-to-Pod communication




For more information:

Filtering load balanced traffic


To configure this filtering, you can use the loadBalancerSourceRanges configuration of the Service object. With this configuration parameter, you can provide a list of CIDR ranges that you would like to allow for access to the Service. If you do not configure loadBalancerSourceRanges, all addresses are allowed to access the Service via its external IP.


For more information, follow the internal load balancing tutorial.

Securing your workloads


Limiting Pod container process privileges

Limiting the privileges of containerized processes is important for the overall security of your cluster. GKE allows you to set security-related options via the Security Context on both Pods and containers. These settings allow you to change security settings of your processes like:

  • User and group to run as
  • Available Linux capabilities
  • Ability to escalate privileges



  • Write files directly in /proc/
  • Mount filesystems

For more information:

Giving Pods access to Google Cloud resources

Your containers and Pods might need access to other resources in Google Cloud. There are three ways to do this.

The simplest and most secure way to authorize Pods to access Google Cloud resources is with Workload Identity. Workload identity allows a Kubernetes service account to run as a Google Cloud service account. Pods that run as the Kubernetes service account have the permissions of the Google Cloud service account.

Workload Identity can be used with GKE Sandbox.

Node Service Account

Your Pods can also authenticate to Google Cloud using the Kubernetes clusters' service account credentials from metadata. However, these credentials can be reached by any Pod running in the cluster if Workload Identity is not enabled. Create and configure a custom service account that has the minimum IAM roles that are required by all the Pods running in the cluster.


Service Account JSON key

A third way to grant credentials for Google Cloud resources to applications is to manually use the service account's key. This approach is strongly discouraged because of the difficulty of securely managing account keys.

You should use application-specific Google Cloud service accounts to provide credentials so that applications have the minimal necessary permissions. Each service account is assigned only the IAM roles that are needed for its paired application to operate successfully. Keeping the service account application-specific makes it easier to revoke its access in the case of a compromise without affecting other applications. Once you have assigned your service account the correct IAM roles, you can create a JSON service account key, and then mount that into your Pod using a Kubernetes Secret.

Using Binary Authorization

Binary Authorization is a service on Google Cloud that provides software supply-chain security for applications that run in the cloud. Binary Authorization works with images that you deploy to GKE from Artifact Registry or another container image registry. With Binary Authorization, you can ensure that internal processes that safeguard the quality and integrity of your software have successfully completed before an application is deployed to your production environment.

For instructions about creating a cluster with Binary Authorization enabled, visit Creating a cluster in the Binary Authorization documentation.

Audit logging

Audit logging provides a way for administrators to retain, query, process, and alert on events that occur in your GKE environments. Administrators can use the logged information to do forensic analysis, real-time alerting, or for cataloging how a fleet of GKE clusters are being used and by whom.

By default, GKE logs Admin Activity logs. You can optionally also log Data Access events, depending on the types of operations you are interested in inspecting.

For more information: