GCP – Announcing general availability of Confidential GKE Nodes
Today, we’re excited to announce the general availability of Confidential GKE Nodes. Many organizations have made Google Kubernetes Engine (GKE) the foundation of their modern application architectures. While the benefits of containers and Kubernetes can outweigh that of traditional architectures, moving to and running those apps in the cloud often entails careful planning to minimize risk and potential data exposure. To help increase security of your GKE clusters, Confidential GKE Nodes can be used.
Part of the growing Confidential Computing product portfolio, Confidential GKE Nodes leverage hardware to make sure your data is encrypted in memory. The GKE workloads you run today can run confidentially without any code changes on your end.
Bringing confidential computing to your container workloads
With Confidential GKE Nodes, you can achieve encryption in-use for data processed inside your GKE cluster, without significant performance degradation. Confidential GKE Nodes are built on the same technology foundation as Confidential VM and utilize AMD Secure Encrypted Virtualization (SEV). This feature allows you to keep data encrypted in memory with node-specific, dedicated keys that are generated and managed by the processor. The keys are generated in hardware during node creation and reside solely within the processor, making them unavailable to Google or other nodes running on the host.
Confidential GKE Nodes also leverage Shielded GKE nodes to offer additional protection against rootkit and bootkits, helping to ensure the integrity of the operating system you run on your Confidential GKE Nodes.
Mixed node pools and stateful workloads
Two new features have been added for the general availability release of Confidential GKE Nodes: mixed node pool support and PersistentVolumes.
Mixing confidential node pools with non-confidential node pools
Confidential GKE Nodes can be enabled as a cluster-level security setting or a node pool-level security setting.
When enabled at the cluster level, Confidential GKE Nodes enforce the use of Confidential VMs on all worker nodes. Worker nodes in a cluster can only use confidential nodes, and confidential computing can not be disabled on individual node pools. All worker nodes, including the workloads running on them, are encrypted in-use.
When enabled at the node level, Confidential GKE Nodes enforce the use of Confidential VMs on specific node pools, so only worker nodes in specified node pools are running confidentially. This new capability can allow a single GKE cluster to run both confidential and non-confidential workloads. Creating regular node pools and confidential node pools in a single cluster can help minimize cluster management. To learn more, see our guide to enabling Confidential GKE Nodes on node pools.
Supporting PersistentVolumes for stateful container workloads
Confidential GKE Nodes are great for protecting data in stateless and stateful workloads. Confidential GKE Nodes recently added support for PersistentVolume resources. In GKE, a PersistentVolume is a cluster resource that Pods can use for durable storage and is typically backed by a persistent disk. The pairing of PersistentVolumes with Confidential GKE Nodes is ideal for containerized applications that require block storage.
Pricing
There is no additional cost to deploy Confidential GKE Nodes, other than the cost of Compute Engine Confidential VM.
Get started with this game-changing technology
Creating a GKE cluster that uses Confidential GKE Nodes on all nodes is easy. Simply go to the Cloud Console, click Kubernetes Engine and then click Clusters. Select “Create” and then “Configure” on GKE Standard. Under Cluster, there is a security section where you click the checkbox that says “Enable Confidential GKE Nodes.”
Confidential computing transforms the way organizations process data in the cloud while preserving confidentiality and privacy. To learn more, read about our Confidential VMs and get started using your own confidential GKE Nodes today.
Read More for the details.