Securing Azure AKS with Customer-Managed Key (CMK) Encryption

Overview

In the Azure cloud, securing data at rest is a fundamental requirement for any serious workload. By default, Azure Kubernetes Service (AKS) encrypts the operating system (OS) and data disks used by your clusters with platform-managed keys (PMK). While this provides a strong baseline of security, it means Microsoft controls the entire key lifecycle. For organizations in regulated industries or with strict data sovereignty requirements, this default level of trust is often insufficient.

Using Customer-Managed Keys (CMK) for AKS disk encryption shifts this control back to your organization. Instead of relying on Azure to manage cryptographic material, you use keys that you create, own, and manage within your own Azure Key Vault. This approach provides a higher level of assurance by separating the control of the keys from the control of the data, a critical principle for a zero-trust security posture. Implementing CMK is an architectural decision that demonstrates a mature approach to data protection, ensuring that your organization has the final say over data accessibility.

Why It Matters for FinOps

From a FinOps perspective, implementing CMK is not just a technical security setting—it has direct business and financial implications. Failing to use CMK where required can result in significant audit failures for compliance frameworks like PCI-DSS, HIPAA, or SOC 2. These failures can lead to steep regulatory fines, jeopardize certifications, and ultimately disqualify your business from securing contracts with enterprise or government clients who mandate this level of control.

Furthermore, CMK introduces a new layer of operational governance. The responsibility for key lifecycle management—including rotation, backup, and revocation—falls entirely on your team. Mismanagement can lead to data inaccessibility or even permanent data loss, causing costly downtime. While there are direct costs associated with Azure Key Vault operations, the primary FinOps concern is managing the risk of non-compliance and the operational overhead required to maintain this defense-in-depth security posture correctly.

What Counts as “Idle” in This Article

In the context of this security control, we aren’t focused on "idle" resources but on "non-compliant" or "misconfigured" resources. An AKS cluster is considered non-compliant if it stores sensitive data but its underlying disks are not encrypted with a Customer-Managed Key as required by your organization’s governance policies.

The primary signal of a non-compliant configuration is an AKS node pool where the disk encryption type is set to the default (using a platform-managed key) instead of being configured for EncryptionAtRestWithCustomerKey. This indicates that a specific Disk Encryption Set linked to a customer-controlled Azure Key Vault is not being used, creating a gap in your data sovereignty and compliance strategy.

Common Scenarios

Scenario 1

A financial technology company deploys a payment processing application on AKS. To comply with PCI-DSS requirements, they must demonstrate full control over the cryptographic keys protecting cardholder data. Using CMK allows them to manage key rotation schedules and access policies, providing auditors with clear evidence that they, not the cloud provider, hold the keys to sensitive financial information.

Scenario 2

A healthcare SaaS provider hosts electronic health records (EHR) on an AKS cluster. Under HIPAA, they are responsible for ensuring the confidentiality of Protected Health Information (PHI). By implementing CMK, they can cryptographically ensure that Azure, as a business associate, cannot access the plaintext PHI. This control is critical for demonstrating due diligence and minimizing trust in the underlying cloud infrastructure.

Scenario 3

A multi-tenant SaaS platform uses a single AKS cluster to serve multiple customers. To ensure cryptographic isolation between tenants, the provider uses CMK. This configuration strengthens tenant data segregation by making it technically impossible for a compromise in one part of the system to expose the keys protecting another tenant’s data, thereby reducing the blast radius of any potential security incident.

Risks and Trade-offs

The primary benefit of CMK is enhanced control, but this comes with significant responsibility. The greatest risk is irreversible data loss. If a Customer-Managed Key is accidentally or maliciously deleted from Azure Key Vault without proper protections in place (like soft-delete and purge protection), all data encrypted with that key becomes permanently unrecoverable. This could instantly destroy an entire production environment.

There is also a significant operational trade-off. While PMK is transparent and requires no management, CMK demands a robust operational practice for key lifecycle management, including key rotation and access control. Furthermore, enabling CMK on AKS OS disks is a decision that must be made when creating a cluster or node pool; it cannot be easily retrofitted, often requiring a full rebuild. Organizations must weigh the compliance and security benefits against this added complexity and the potential for catastrophic failure if mismanaged.

Recommended Guardrails

To implement CMK safely and effectively, FinOps and security teams should establish clear guardrails.

• Policy Enforcement: Use Azure Policy to mandate that all new AKS clusters deployed in sensitive environments are configured with CMK by default.
• Ownership and Separation of Duties: Define clear ownership roles. A central security team should manage the Azure Key Vaults and key lifecycle, while application teams manage the AKS clusters. This separation prevents a single compromised identity from controlling both the data and the keys.
• Tagging Standards: Implement a data classification tagging strategy to identify which AKS clusters host sensitive data and therefore require CMK. This helps focus enforcement and audit efforts where they matter most.
• Budgets and Alerts: Monitor the costs associated with Azure Key Vault operations. While typically low, high-volume key operations could indicate misconfigurations or abuse. Set up alerts for unusual activity.

Provider Notes

Azure

Implementing this control in Azure involves the orchestrated use of three core services. The process relies on Azure Kubernetes Service (AKS), the managed container orchestration service. The customer-managed keys themselves are securely stored and managed in Azure Key Vault, which can be backed by a FIPS 140-2 validated Hardware Security Module (HSM) for the highest level of security. The critical link between your AKS disks and your Key Vault is a resource called a Disk Encryption Set (DES). This resource references the specific key in the vault and is assigned an identity that is granted permissions to use the key for cryptographic operations.

Binadox Operational Playbook

Binadox Insight: Adopting Customer-Managed Keys is a statement of security maturity. It transfers the root of trust from the cloud provider to your organization, but with it comes the non-negotiable responsibility for flawless key management. Missteps are not just operational errors; they are potentially catastrophic data loss events.

Binadox Checklist:

• Inventory all current AKS clusters and classify the sensitivity of the data they manage.
• Define a corporate policy that specifies which data classifications require CMK encryption.
• Configure a dedicated Azure Key Vault for AKS keys with soft-delete and purge protection enabled.
• Establish and document a secure process for key generation, rotation, and revocation.
• Use Azure Policy to audit for AKS clusters that are non-compliant with your CMK policy.
• Plan for the migration or recreation of existing clusters that need to be retrofitted with CMK.

Binadox KPIs to Track:

• Percentage of production AKS clusters compliant with CMK policy.
• Mean Time to Remediate (MTTR) for newly discovered non-compliant clusters.
• Frequency of successful key rotation cycles across all managed keys.
• Azure Key Vault operational costs attributed to AKS encryption.

Binadox Common Pitfalls:

• Forgetting to enable soft-delete and purge protection on the Azure Key Vault, exposing keys to permanent deletion.
• Attempting to enable CMK on the OS disks of an existing AKS node pool, which is not supported and requires a rebuild.
• Lacking a documented key lifecycle management plan, leading to missed key rotations or chaos during an emergency revocation.
• Underestimating the operational discipline required to manage keys, leading to security gaps or availability incidents.

Conclusion

Encrypting Azure AKS disks with Customer-Managed Keys is an essential security control for any organization handling sensitive or regulated data. It moves beyond baseline security to provide true data sovereignty, granular control, and a clear path to demonstrating compliance with stringent industry standards.

While it introduces operational responsibilities, the benefits of control and risk reduction are indispensable for a mature cloud security posture. The next step is to evaluate your workloads, identify those that require this advanced protection, and build the governance and operational playbooks necessary to manage it effectively.