Encrypt workload data in-use with Confidential GKE Nodes

Standard

---

This page shows you how to enforce encryption of data in-use in your nodes and workloads by using Confidential Google Kubernetes Engine Nodes. Enforcing encryption can help increase the security of your workloads.

This page is for Security specialists who implement security measures on GKE. To learn more about common roles and example tasks that we reference in Google Cloud content, see Common GKE Enterprise user roles and tasks.

Before reading this page, ensure that you're familiar with the concept of data-in-use.

What is Confidential GKE Nodes?

You can encrypt your workloads with Confidential GKE Nodes or Confidential mode for Hyperdisk Balanced.

Confidential GKE Nodes

Confidential GKE Nodes is built on top of Compute Engine Confidential VM using AMD Secure Encryption Virtualization (SEV), which encrypts the memory contents of VMs in-use. Encryption-in-use is one of the three states of end-to-end encryption.

Confidential GKE Nodes doesn't change the security measures that GKE applies to cluster control planes. To learn about these measures, see Control plane security. For visibility over who accesses control planes in your Google Cloud projects, use Access Transparency.

You can do the following to enable Confidential GKE Nodes:

• Create a new cluster
• Deploy a workload with node auto-provisioning
• Create a node pool
• Update an existing node pool

You can't update an existing cluster to change the cluster-level Confidential GKE Nodes setting.

The following table shows you the GKE behavior that applies when you enable Confidential GKE Nodes:

Confidential GKE Nodes setting	How to configure	Behavior
Cluster level	Create a new Autopilot or Standard mode cluster	All nodes use Confidential GKE Nodes. This operation is irreversible. You can't override the setting for individual nodes. In GKE Autopilot clusters, all nodes automatically use the default machine series for the Balanced compute class, which is N2D.
Node pool level	Create a new Standard node pool Update an existing Standard node pool	GKE encrypts the memory contents of nodes in that node pool. This is only possible if Confidential GKE Nodes is disabled at the cluster level.

Confidential mode for Hyperdisk Balanced

You can also enable Confidential mode for Hyperdisk Balanced on your boot disk storage which encrypts your data on additional hardware-backed enclaves.

You can enable Confidential mode for Hyperdisk Balanced when doing one of the following:

• Create a new cluster
• Create a new node pool

You cannot update an existing cluster or a node pool to change the Confidential mode for Hyperdisk Balanced setting.

The following table shows you the GKE behavior that applies when you enable Confidential mode for Hyperdisk Balanced setting at the cluster level or at the node pool level:

Confidential mode for Hyperdisk Balanced setting	How to configure	Behavior
Cluster-level	Create a new cluster	Only the default node pool in the cluster will use Confidential mode for Hyperdisk Balanced setting. You cannot do the following: Disable Confidential mode for Hyperdisk Balanced setting for an existing node pool in the cluster Enable Confidential mode for Hyperdisk Balanced setting on existing clusters
Node pool level	Create a new node pool	You can configure Confidential mode for Hyperdisk Balanced setting for any new node pools at creation time. You can't update existing node pools to use Confidential mode for Hyperdisk Balanced setting.

Pricing

The following pricing applies:

• Autopilot:

  1. You incur costs based on the Balanced compute class pricing because enabling Confidential GKE Nodes changes the default machine series in the cluster to N2D. For pricing details, see Autopilot pricing.
  2. You incur costs for Confidential GKE Nodes in addition to the GKE Autopilot pricing. For details, see the "Confidential GKE Nodes on GKE Autopilot pricing" section in Confidential VM pricing.

• Standard: There is no additional cost to deploy Confidential GKE Nodes, other than the cost of Compute Engine Confidential VM. However, Confidential GKE Nodes might generate slightly more log data on startup than standard nodes. For information on logs pricing, see Pricing for Google Cloud Observability.

Availability

Confidential GKE Nodes is available as follows:

• Autopilot: Available in GKE version 1.30.2 and later.

• Standard: Available with the N2D machine series or the C2D machine series.

• Confidential GKE Nodes is only available in zones and regions with N2D instances, C2D instances, or C3D instances available.

• Confidential GKE Nodes can be used with Container-Optimized OS and Container-Optimized OS with containerd (cos_containerd).

Before you begin

Before you start, make sure you have performed the following tasks:

• Enable the Google Kubernetes Engine API.
Enable Google Kubernetes Engine API
• If you want to use the Google Cloud CLI for this task, install and then initialize the gcloud CLI. If you previously installed the gcloud CLI, get the latest version by running gcloud components update.
  Note: For existing gcloud CLI installations, make sure to set the compute/region and compute/zone properties. By setting default locations, you can avoid errors in gcloud CLI like the following: One of [--zone, --region] must be supplied: Please specify location.

Use Confidential GKE Nodes in Autopilot

You can enable Confidential GKE Nodes for an entire Autopilot cluster, which makes every node a confidential node. All your workloads run on confidential nodes with no changes needed to workload manifests. Enabling Confidential GKE Nodes changes the default machine series in the cluster to N2D.

Enable Confidential GKE Nodes on a new Autopilot cluster

Caution: Enabling Confidential GKE Nodes on a new cluster is irreversible.

Run the following command:

gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --enable-confidential-nodes

Replace the following:

• CLUSTER_NAME: the name of the Autopilot cluster.
• LOCATION: the Compute Engine location for the cluster.

The cluster must run version 1.30.2 or later. To set a specific version when you create a cluster, see Set the version and release channel of a new Autopilot cluster.

Use Confidential GKE Nodes in Standard mode

You can enable Confidential GKE Nodes at the cluster level or at the node pool level in Standard mode.

Enable Confidential GKE Nodes on Standard clusters

Caution: Enabling Confidential GKE Nodes at the cluster level is irreversible.

You can create a new cluster with Confidential GKE Nodes enabled by using the gcloud CLI or the Google Cloud console. If you enable Confidential GKE Nodes at the cluster level, all the nodes in the cluster are Confidential VM.

You can also use Confidential GKE Nodes in clusters that use node auto-provisioning to automatically scale node pools.

gcloud

When creating a new cluster, specify the --enable-confidential-nodes option in the gcloud CLI:

gcloud container clusters create CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --enable-confidential-nodes

Note: You can enable confidential mode on boot disk storage by passing the --enable-confidential-storage flag and --boot-disk-kms-key=KMS_KEY. For more information, see the KMS key documentation.

Replace the following:

• CLUSTER_NAME: the name of your new cluster.
• MACHINE_TYPE: the machine type for your cluster's default node pool, which must be the N2D, C2D, or C3D machine type.

Console

1. Go to the Google Kubernetes Engine page in the Google Cloud console.

   Go to Google Kubernetes Engine

2. Click Create.

3. In the Standard section, click Configure.

4. From the navigation pane, under Cluster, click Security.

5. Select the Enable Confidential GKE Nodes checkbox.

6. Configure your cluster as needed.

7. Click Create.

See Creating a regional cluster for more details about creating clusters.

After creating a cluster with Confidential GKE Nodes, any node pools created in this cluster can only use confidential nodes. You cannot create regular node pools in clusters with Confidential GKE Nodes enabled. You also cannot disable Confidential GKE Nodes on individual node pools when you enable Confidential GKE Nodes at the cluster level.

For any node pool created with the Confidential mode for Hyperdisk Balanced setting, only the nodes in the node pool are restricted to the setup configuration. For any new node pools created in the cluster, you must set up confidential mode at creation.

Enable Confidential GKE Nodes on node pools

You can enable Confidential GKE Nodes on specific node pools if Confidential GKE Nodes is disabled at the cluster level.

Confidential mode for Hyperdisk Balanced setting must be specified during node pool creation request.

Create a new node pool

To create a new node pool with Confidential GKE Nodes enabled, run the following command:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --enable-confidential-nodes

Note: You can enable confidential mode on boot disk storage by passing the --enable-confidential-storage flag and --boot-disk-kms-key=KMS_KEY. For more information, see the KMS key documentation

Replace the following:

• NODE_POOL_NAME: the name of your new node pool.
• CLUSTER_NAME: the name of your cluster.
• MACHINE_TYPE: the machine type for your node pool, which must be a N2D, C2D, or C3D machine type.

Update an existing node pool

You can enable Confidential GKE Nodes on existing node pools that use the N2D, C2D, or C3D machine types. Run the following command:

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --enable-confidential-nodes

Replace the following:

• NODE_POOL_NAME: the name of your node pool.
• CLUSTER_NAME: the name of your cluster.

This change requires recreating the nodes, which can cause disruption to your running workloads. For details about this specific change, find the corresponding row in the manual changes that recreate the nodes using a node upgrade strategy without respecting maintenance policies table. To learn more about node updates, see Planning for node update disruptions.

Caution: GKE immediately begins recreating the nodes for this change using the node upgrade strategy, regardless of active maintenance policies. GKE depends on resource availability for the change. Disabling node auto-upgrades doesn't prevent this change. Ensure that your workloads running on the nodes are prepared for disruption before you initiate this change.

Place workloads on only Confidential GKE Nodes node pools

If you enable Confidential GKE Nodes at the cluster level, all of your workloads run on confidential nodes. You don't need to make changes to your manifests. However, if you only enable Confidential GKE Nodes for specific node pools, you should declaratively express that your workloads must only run on node pools with Confidential GKE Nodes. Use the cloud.google.com/gke-confidential-nodes node selector, like in the following example:

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: my-confidential-app
    image: us-docker.pkg.dev/myproject/myrepo/my-confidential-app
  nodeSelector:
    cloud.google.com/gke-confidential-nodes: "true"

Verify that Confidential GKE Nodes are enabled

You can check whether your clusters or nodes use Confidential GKE Nodes by inspecting the clusters or nodes.

On Autopilot mode or Standard mode clusters

You can verify that your Autopilot or Standard cluster is using Confidential GKE Nodes with the gcloud CLI or the Google Cloud console.

gcloud

Describe the cluster:

gcloud container clusters describe CLUSTER_NAME

If Confidential GKE Nodes is enabled, the output of the command includes the following lines:

confidentialNodes:
  enabled: true

Console

1. Go to the Google Kubernetes Engine page in the Google Cloud console.

   Go to Google Kubernetes Engine

2. Click the name of the cluster you want to inspect.

3. Under Security, in the Confidential GKE Nodes field, verify that Confidential GKE Nodes is Enabled.

On Autopilot mode or Standard mode nodes

To verify whether specific Autopilot or Standard nodes use Confidential GKE Nodes, do the following:

1. Find the node name:

   kubectl get nodes
   

2. Describe the node:

   kubectl describe NODE_NAME
   

   Replace NODE_NAME with the name of a node to inspect.

If Confidential GKE Nodes is enabled, the output includes the following:

# lines omitted for clarity
cloud.google.com/gke-confidential-nodes=true

On Standard mode node pools

To verify that your node pool is using Confidential GKE Nodes, run the following command:

gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME

If Confidential GKE Nodes is enabled, the output is similar to the following:

confidentialNodes:
  enabled: true

If Confidential mode for Hyperdisk Balanced setting is enabled, the output is similar to the following:

enableConfidentialStorage: true

On individual Standard mode nodes

To validate the confidentiality of specific nodes in Standard clusters, you can do the following:

1. Validate AMD SEV is enabled, or
2. Validate Confidential VM using Cloud Monitoring.

Set organization policy constraints

You can define an organization policy constraint to ensure that all VM resources created across your organization are Confidential VM instances. For GKE, you can customize the Restrict Non-Confidential Computing constraint to require that all new clusters are created with Confidential GKE Nodes enabled. Add the container.googleapis.com API Service name to the deny list when enforcing organization policy constraints, for example:

gcloud resource-manager org-policies deny \
    constraints/compute.restrictNonConfidentialComputing compute.googleapis.com container.googleapis.com \
    --project=PROJECT_ID

Replace PROJECT_ID with your project ID.

Create a PersistentVolume for Confidential mode for Hyperdisk Balanced

For guidance on allowable values for throughput or IOPS, see Plan the performance level for your Hyperdisk volume.

The following examples show how you can create a Confidential mode for Hyperdisk Balanced StorageClass for each Hyperdisk type:

Hyperdisk Balanced

1. Save the following manifest in a file named confidential-hdb-example-class.yaml:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: balanced-storage
   provisioner: pd.csi.storage.gke.io
   volumeBindingMode: WaitForFirstConsumer
   allowVolumeExpansion: true
   parameters:
     type: hyperdisk-balanced
     provisioned-throughput-on-create: "250Mi"
     provisioned-iops-on-create: "7000"
     enable-confidential-storage: true
     disk-encryption-kms-key: "projects/KMS_PROJECT_ID/locations/REGION/keyRings/KEY_RING/cryptoKeys/HSM_KEY_NAME"
   

   Replace the following:

   • KMS_PROJECT_ID: the project that owns the Cloud KMS key
   • REGION: the region where the disk is located
   • KEY_RING: the name of the key ring that includes the key
   • HSM_KEY_NAME: the name of the HSM key used to encrypt the disk

2. Create the StorageClass:

   kubectl create -f hdb-example-class.yaml
   

3. Create a Hyperdisk Persistent Volume Claim for GKE that uses your Confidential mode for Hyperdisk Balanced volume.

To find the name of the StorageClasses available in your cluster, run the following command:

kubectl get sc

Limitations

Confidential GKE Nodes has the following limitations:

• All the limitations of Compute Engine Confidential VM instances apply to Confidential GKE Nodes.
• Confidential GKE Nodes that have the C2D machine type can only use node auto-provisioning in GKE version 1.24 or later.
• Confidential GKE Nodes only supports PersistentVolumes backed by persistent disks if your control plane runs GKE version 1.22 or later. For instructions, refer to Using the Compute Engine persistent disk CSI Driver .
• Confidential GKE Nodes is not compatible with GPUs.
• Confidential GKE Nodes is not compatible with sole tenant nodes.
• Confidential GKE Nodes only supports using ephemeral storage on local SSDs, but doesn't support using local SSDs in general.
• Only Container-Optimized OS nodes are supported. Ubuntu and Windows nodes are not supported.

Disable Confidential GKE Nodes

You can only disable Confidential GKE Nodes in Standard mode node pools. If the node pool is in a cluster that uses Confidential GKE Nodes at the cluster level, you can't disable the feature at the node pool level.

• See Limitations section for additional Confidential mode for Hyperdisk Balanced information.
• Confidential mode for Hyperdisk Balanced is supported only on Confidential GKE Nodes.

Live migration limitations

Certain Compute Engine Confidential VM machine types support live migration, which minimizes the potential workload disruption from a host maintenance event. Live migration occurs in the following GKE versions:

• 1.27.10-gke.1218000 and later
• 1.28.6-gke.1393000 and later
• 1.29.1-gke.1621000 and later

If your node pools were already running a supported version when live migration was added, manually upgrade the node pools to the same or a different supported version. Upgrading the nodes triggers node recreation, and the new nodes have live migration enabled.

For details about which Compute Engine machine types support live migration, see Supported configurations.

If a host maintenance event occurs on a node that doesn't support live migration, the node enters a NotReady state. Running Pods will experience disruptions until the node becomes ready again. If the maintenance takes more than five minutes, GKE might try to recreate the Pods on other nodes.

Disable Confidential GKE Nodes

Disabling Confidential GKE Nodes only works for node pools that have enabled Confidential GKE Nodes. If the cluster is created with Confidential GKE Nodes, you cannot disable the feature. Run the following command to disable Confidential GKE Nodes on a node pool:

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --no-enable-confidential-nodes

This change requires recreating the nodes, which can cause disruption to your running workloads. For details about this specific change, find the corresponding row in the manual changes that recreate the nodes using a node upgrade strategy without respecting maintenance policies table. To learn more about node updates, see Planning for node update disruptions.

Caution: GKE immediately begins recreating the nodes for this change using the node upgrade strategy, regardless of active maintenance policies. GKE depends on resource availability for the change. Disabling node auto-upgrades doesn't prevent this change. Ensure that your workloads running on the nodes are prepared for disruption before you initiate this change.

What's next

• Learn more about Confidential VM.
• Learn more about node images.
• Learn more about Google Cloud encryption at rest.
• Learn more about Google Cloud encryption in transit.
• Learn more about customer-managed encryption keys (CMEK).
• Learn more about application-layer secrets encryption.