Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure Kubernetes Service (AKS) stores sensitive data such as Kubernetes secrets in etcd, the distributed key-value store used by Kubernetes. For enhanced security and compliance requirements, AKS supports encryption of Kubernetes secrets at rest using the Kubernetes Key Management Service (KMS) provider integrated with Azure Key Vault.
This article explains the key concepts, encryption models, and key management options available for protecting Kubernetes secrets at rest in AKS.
Understanding data encryption at rest
Data encryption at rest protects your data when it's stored on disk. Without encryption at rest, an attacker who gains access to the underlying storage could potentially read sensitive data like Kubernetes secrets.
AKS provides encryption for Kubernetes secrets stored in etcd:
| Layer | Description |
|---|---|
| Azure platform encryption | Azure Storage automatically encrypts all data at rest using 256-bit AES encryption. This encryption is always enabled and transparent to users. |
| KMS provider encryption | An optional layer that encrypts Kubernetes secrets before they're written to etcd using keys stored in Azure Key Vault. |
For more information about Azure's encryption at rest capabilities, see Azure data encryption at rest and Azure encryption models.
KMS provider for data encryption
The Kubernetes KMS provider is a mechanism that enables encryption of Kubernetes secrets at rest using an external key management system. AKS integrates with Azure Key Vault to provide this capability, giving you control over encryption keys while maintaining the security benefits of a managed Kubernetes service.
How KMS encryption works
When you enable KMS for an AKS cluster:
- Secret creation: When a secret is created, the Kubernetes API server sends the secret data to the KMS provider plugin.
- Encryption: The KMS plugin encrypts the secret data using a Data Encryption Key (DEK), which is itself encrypted using a Key Encryption Key (KEK) stored in Azure Key Vault.
- Storage: The encrypted secret is stored in etcd.
- Secret retrieval: When a secret is read, the KMS plugin decrypts the DEK using the KEK from Azure Key Vault, then uses the DEK to decrypt the secret data.
This envelope encryption approach provides both security and performance benefits. The DEK handles frequent encryption operations locally while the KEK in Azure Key Vault provides the security of a hardware-backed key management system.
Key management options
AKS offers two key management options for KMS encryption:
Platform-managed keys (PMK)
With platform-managed keys, AKS automatically manages the encryption keys for you:
- AKS creates and manages the Azure Key Vault and encryption keys.
- Key rotation is handled automatically by the platform.
- No additional configuration or key vault setup is required.
When to use platform-managed keys:
- You want the simplest setup with minimal configuration.
- You don't have specific regulatory requirements that mandate customer-managed keys.
- You want automatic key rotation without manual intervention.
Customer-managed keys (CMK)
With customer-managed keys, you have full control over the encryption keys:
- You create and manage your own Azure Key Vault and encryption keys.
- You control key rotation schedules and policies.
When to use customer-managed keys:
- You have regulatory or compliance requirements that mandate customer-managed keys.
- You need to control the key lifecycle, including rotation schedules and key versions.
- You require audit logs for all key operations.
Key vault network access options
When using customer-managed keys, you can configure the network access for your Azure Key Vault:
| Network access | Description | Use case |
|---|---|---|
| Public | Key vault is accessible over the public internet with authentication. | Development environments, simpler setup |
| Private | Key vault has public network access disabled. AKS accesses the key vault through the trusted services firewall exception. | Production environments, enhanced security |
Comparing encryption key options
| Feature | Platform-managed keys | Customer-managed keys (Public) | Customer-managed keys (Private) |
|---|---|---|---|
| Key ownership | Microsoft manages | Customer manages | Customer manages |
| Key rotation | Automatic | User configurable | User configurable |
| Key vault creation | Automatic | Customer creates | Customer creates |
| Network isolation | N/A | No | Yes |
Requirements
- The new KMS encryption with platform-managed keys or customer-managed keys with automatic key rotation experience requires Kubernetes version 1.33 or later.
- The new KMS encryption with platform-managed keys or customer-managed keys with automatic key rotation experience is only supported on AKS clusters where managed identity is used for the cluster's identity.
Limitations
- No downgrade: After enabling the new KMS encryption experience, you can't disable the feature.
- Key deletion: Deleting the encryption key or key vault makes your secrets unrecoverable.
- Private endpoint access: Key vault access using private link/endpoint isn't yet supported. For private key vaults, use the trusted services firewall exception.