About GKE control plane authority

Autopilot Standard

This page describes the options that Google Kubernetes Engine (GKE) offers to improve your visibility and control over the security of the managed control plane. These options are collectively referred to as GKE control plane authority. This page is intended for information security leaders, compliance administrators, and analysts who want to meet strict privacy and security needs for handling sensitive data.

About GKE control plane authority features

In GKE, Google Cloud fully manages the security configuration of the control plane, including encryption of storage at rest, and configuring the keys and certificate authorities (CAs) that sign and verify credentials in your clusters. The control plane nodes for GKE clusters exist in projects that Google Cloud manages. For details about what Google Cloud does, see GKE shared responsibility.

GKE control plane authority is an optional set of visibility and control capabilities that let you verify and manage specific aspects of these fully-managed control plane nodes. These capabilities are ideal if you have requirements like the following:

You operate in a highly regulated industry like finance, healthcare, or government with specific compliance requirements
You handle sensitive data that has strict security and encryption requirements
You want enhanced visibility over GKE to improve your confidence when running critical workloads
You have to meet specific compliance or auditing requirements related to data encryption, software integrity, or logging
You have highly-sensitive workloads that process critical data, and you want visibility into the encryption of and access to that data
You want to enforce custom security policies that meet specific organizational or regulatory requirements
You want an enhanced level of transparency and visibility into your GKE environments, especially related to actions that Google Cloud takes in the control plane

Benefits of GKE control plane authority

GKE control plane authority capabilities are ideal in highly regulated environments that have strict security policies or strict audit requirements. Using these capabilities grants benefits like the following:

Enhanced visibility and control: Use additional visibility, control, and encryption capabilities for your GKE control plane.
Risk mitigation: Proactively detect and respond to potential threats to the managed control plane with comprehensive logs.
Standardized CA and key management: Manage your GKE cluster CAs using Certificate Authority Service, letting you delegate certificate management to specific teams and letting you comprehensively enforce CA policies. Additionally, manage your control plane disk encryption keys using Cloud KMS for similar management delegation.

Key and credential management

By default, Google Cloud manages the keys and CAs in your GKE clusters for you. You can optionally use Cloud KMS and CA Service to set up your own keys and CAs, which you then use when creating a new cluster.

GKE uses these keys and CAs instead of the Google Cloud defaults to issue and verify identities in your cluster and to encrypt data in your control plane VMs. Maintaining control over your identity issuance and data encryption keys can help you to do the following:

Comply with data sovereignty and privacy regulations that mandate exclusive control over keys
Control the encryption of critical sensitive data in Kubernetes by managing your own encryption keys
Customize your data encryption strategy based on your organization's policies and requirements, like requirements to use hardware-backed keys.

Self-managed CAs and service account keys

You can configure the GKE control plane to use Cloud KMS keys and CA Service CAs that you manage. GKE uses these resources to issue and verify identities in your cluster. For example, GKE uses CAs and keys to issue Kubernetes client certificates and Kubernetes service account bearer tokens.

You create the following resources for GKE to use when issuing identities:

Service Account signing keys: sign the Kubernetes ServiceAccount bearer tokens for service accounts in the cluster. These bearer tokens are JSON Web Tokens (JWTs) that facilitate Pod communication with the Kubernetes API server.
Service Account verification keys: verify the Kubernetes Service Account JWTs. This key is normally the same as the signing key, but is configured separately so that you can rotate your keys more safely.
Cluster CA: issue signed certificates for purposes like certificate signing requests (CSRs) and kubelet communication.
etcd peer CA: issue signed certificates for communication between etcd instances in the cluster.
etcd API CA: issue signed certificates for communication with the etcd API server.
Aggregation CA: issue signed certificates for enabling communication between the Kubernetes API server and extension servers.

When GKE issues identities in the cluster, you see the corresponding audit logs in Cloud Logging, which you can use to track issued identities over their lifetime.

To learn more, see Run your own certificate authorities and signing keys in GKE.

Control plane boot disk and etcd encryption

By default, GKE encrypts the boot disk of a control plane VM, the disk that stores data in etcd, and the Google Cloud internal operational backup of etcd by using encryption keys that Google Cloud manages. For details about this default encryption, see Default encryption at rest.

You can optionally use your own encryption keys that you manage using Cloud KMS to encrypt the following resources:

Control plane boot disk: the Compute Engine disk that each control plane VM uses to boot.
etcd disk: the Compute Engine disk that's attached to each control plane VM and stores data for etcd instances in the cluster.
etcd internal operational backup: the internal Google Cloud backup of etcd that's used for operational purposes like disaster recovery.

This backup is an emergency measure internal to Google Cloud. If you want to back up and restore your clusters, use backup for GKE instead.

For instructions, see Encrypt etcd and control plane boot disks.

This additional optional encryption is ideal if you have to meet specific regulatory or compliance requirements related to controlling the means of encryption in your cluster control plane. You can separately use your own keys to encrypt the boot disks and storage disks of worker nodes in your cluster. For details, see Use customer-managed encryption keys (CMEK).

When you use GKE control plane authority to encrypt your control plane boot disks, GKE control plane VMs automatically use Confidential mode for Hyperdisk Balanced in the boot disks. This configuration doesn't change the default boot disks of your worker nodes.

Additional resources about control plane security

This section describes other methods that you can use to improve your confidence in your control plane security. You don't need to use GKE control plane authority to use the following resources:

Control plane VM image integrity: GKE adds detailed logs for node VM creation and boot events to Cloud Logging. Additionally, we publish SLSA VSAs on GitHub that correspond to control plane and worker node machine images. You can verify that your VMs use OS images that have corresponding VSAs and verify the boot integrity of each control plane VM.

To perform VM integrity verification, see Verify GKE control plane VM integrity.
Built-in control plane security measures: GKE performs various hardening measures on the managed control plane. To learn more, see Control plane security.