[New Check]: aks_cluster_kms_cmk_encryption_enabled #12862

Existing check search

• I have searched existing issues, Prowler Hub, and the public roadmap, and this check does not already exist.

Provider

Azure

New provider name

No response

Service or product area

aks

Suggested check name

aks_cluster_kms_cmk_encryption_enabled

Context and goal

• Security condition to validate: AKS clusters encrypt Kubernetes Secrets at rest in etcd with a customer-managed key held in Azure Key Vault.

• Why it matters: Kubernetes Secrets are stored in etcd base64-encoded, not encrypted at the application layer. The AKS control plane including etcd is operated by Microsoft, so by default the subscription owner has no independent control over secrets at rest. Enabling KMS with a customer-managed key moves the protecting key into the customer's own Key Vault, which makes access revocable from the customer side, records every use of the key in the customer's tenant, and supports customer-managed key requirements from auditors and contracts.

• Note on platform-managed keys: AKS now also offers KMS with platform-managed keys, where the platform creates and rotates the key. That option does not satisfy this control, because Microsoft continues to hold the key. This check is scoped to customer-managed keys, which is why the name carries cmk, consistent with the AWS check eks_cluster_kms_cmk_encryption_in_secrets_enabled.

• Resource, feature, or configuration involved: Microsoft.ContainerService/managedClusters, property securityProfile.azureKeyVaultKms.

Expected behavior

• Resource or scope to evaluate: every AKS managed cluster in the audited subscriptions.

• PASS when: securityProfile.azureKeyVaultKms.enabled is true, meaning a customer-managed Key Vault key is in use.

• FAIL when: securityProfile.azureKeyVaultKms.enabled is false, or the KMS block or the security profile itself is absent, which is the default state for a cluster that never enabled the feature. Clusters using KMS with platform-managed keys also fail, since Microsoft still holds the key.

• Exclusions, thresholds, or edge cases: the check evaluates whether a customer-managed key is in use, nothing more. It does not judge keyVaultNetworkAccess (Public or Private), key rotation age, or whether the referenced key still exists. Those are separable concerns and would suit follow-up checks.

References

• Data encryption at rest concepts for AKS: https://learn.microsoft.com/en-us/azure/aks/kms-data-encryption-concepts
• Enable KMS data encryption in AKS: https://learn.microsoft.com/en-us/azure/aks/kms-data-encryption
• Legacy KMS etcd encryption, still the generally available path: https://learn.microsoft.com/en-us/azure/aks/use-kms-etcd-encryption
• Upstream Kubernetes KMS provider: https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/
• ARM reference: https://learn.microsoft.com/en-us/azure/templates/microsoft.containerservice/managedclusters
• SDK: azure-mgmt-containerservice, ManagedCluster.security_profile.azure_key_vault_kms, model AzureKeyVaultKms with fields enabled, key_id, key_vault_network_access, key_vault_resource_id
• CLI: az aks update --enable-azure-keyvault-kms --azure-keyvault-kms-key-id --assign-identity
• Prior art in Prowler: eks_cluster_kms_cmk_encryption_in_secrets_enabled covers the equivalent control on AWS

Suggested severity

Medium

Additional implementation notes

• Required permissions or scopes: none beyond what the AKS service already uses. The field is present on the ManagedCluster objects the service fetches today, so this adds no API call.
• Configurable behavior or thresholds: none needed.
• Other constraints: enabling KMS is not a single flag. It requires a user-assigned managed identity, since system-assigned is not supported for this feature, and a Key Vault with soft delete and purge protection enabled, because deleting or purging the key makes every Secret already written to etcd permanently unrecoverable. The check reports on cluster state only and does not attempt to validate the vault configuration.
• On the newer platform-managed key experience: it sets securityProfile.kubernetesResourceObjectEncryptionProfile.infrastructureEncryption rather than azureKeyVaultKms. That property is not modelled in the azure-mgmt-containerservice version currently pinned by Prowler, so it cannot be read today. It is also not needed for this check, which is scoped to customer-managed keys.