Application development continues to move towards a container-based approach, and our efforts in securing this space bring us to this exciting launch. Earlier this year, we previewed confidential VM nodes in Azure Kubernetes Service (AKS), a leader in development and deployment of cloud native apps. AKS is first in market to leverage AMD SEV-SNP confidential VMs for memory-encrypted nodes, and with this launch, we introduce you to the expanded attestation capabilities and path to deployment.
Confidential computing helps customers have verifiable assurance that their workloads (both data and code) are protected from the time they are created until the time they are destroyed. To help developers and operators accelerate the adoption of confidential computing, we have lowered the bar to easily onboard cloud native applications to AKS. This capability will help you meet data security goals and add to defense in depth without adding developer and operational overhead.
With the general availability of confidential VM nodes in AKS there are also no additional compute costs to using these confidential VM nodes other than those associated with VM SKU sizes.
Attestation of confidential VM nodes
In line with Microsoft’s Zero Trust policy – we empower our customers to verify that they’re running on genuine, trusted hardware. Customers can leverage an open-source application to generate the SNP attestation report from the hardware which hosts your VM nodes on AKS – and use this to cryptographically attest that your code will be executed on AMD SEV-SNP hardware. Additionally, you can leverage simple node pool affinity annotations through pod spec yaml/helm changes to target your workload on nodes where the SNP attestation report is generated, or in the initialization (initrd) of your container to ensure it only executes on an attested node.
Here is a simple yaml file with specifications for confidential VM node deployment (see highlighted part). This will ensure that your container will only run on nodes with Security Type as ConfidentialVM. This security type is automatically added to the DC-series and EC-series confidential VM SKU sizes.
- image: mcr.microsoft.com/acc/samples/cvm-attestation:1.1
- mountPath: /sys/kernel/security
- mountPath: /dev/tpmrm0
- name: tcg
- name: tpmrm0
Easy path to deployment
We have simplified the process to create nodes on confidential VMs - it is choosing a confidential VM SKU size during node pool creation. You can learn more about sizes and specs for general purpose (DC -series) and memory-optimized (EC- series) confidential VMs. We have enabled both the Azure portal and CLI experience – for ease of use by organization admins and automated scripts alike.
Here is a small demo to create an AKS cluster with a confidential VM node through the Azure portal. We choose the DC2ads_v5 confidential VM SKU size in this example.
Enhanced security and memory-encryption in use
Our partnership with Canonical enables the full lift-and-shift of Linux workloads on Kubernetes managed infrastructure to confidential VM nodes in Azure. We’re also expanding support to Windows workloads, coming soon! This helps protect your organization from memory dumps performed maliciously by neighboring VMs to more sophisticated attack vectors. Check out this Microsoft Mechanics video to learn more about protection against these attacks.
AKS is also equipped to have confidential and non-confidential node pools in a single cluster. This enables you to split your workload to process sensitive data in a confidential VM node, where memory encryption keys are generated from the chipset itself.
Confidential VM nodes on AKS opens a world of workload migration opportunities – previously tethered to on-prem computing resources for security, regulatory or compliance concerns. We invite you to check out our demo at the Ignite keynote for Cloud Native Kubernetes. You can also check out our published samples here.