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.
This article describes the Policy guardrails in place to ensure Azure Kubernetes Service is deployed securely.
Initiative details
Azure Enclave assigns the AKS guardrails initiative (policy set definition ID d300338e-65d1-4be3-b18e-fb4ce5715a8f) to workload resource groups.
The Effect values in the tables show the effects supported by the policy definitions. The effective behavior of a policy assignment can vary based on Azure Enclave policy configuration and policy parameters.
The initiative references the KMS policy twice with different reference IDs. This table lists each unique policy definition once.
AKS GitHub Repository
AKS Policies Built in
| Name | Description | Version | Type | Supported definition effect | Policy definition |
|---|---|---|---|---|---|
| Authorized IP ranges should be defined on Kubernetes Services | Restrict access to the Kubernetes Service Management API by granting API access only to IP addresses in specific ranges. Limit access to authorized IP ranges to ensure that only applications from allowed networks can access the cluster. | 2.0.1 | BuiltIn | Audit, Disabled | Link |
| Azure Kubernetes Clusters should enable Key Management Service (KMS) | Use Key Management Service (KMS) to encrypt secret data at rest in etcd for Kubernetes cluster security. Learn more at: https://aka.ms/aks/kmsetcdencryption. | 1.1.0 | BuiltIn | Audit, Disabled | Link |
| Azure Kubernetes Service Clusters should disable Command Invoke | Disabling command invoke can enhance the security by avoiding bypass of restricted network access or Kubernetes role-based access control | 1.0.1 | BuiltIn | Audit, Disabled | Link |
| Azure Kubernetes Service Private Clusters should be enabled | Enable the private cluster feature for your Azure Kubernetes Service cluster to ensure network traffic between your API server and your node pools remains on the private network only. This requirement is common in many regulatory and industry compliance standards. | 2.0.0 | BuiltIn | Audit, Disabled | Link |
| Both operating systems and data disks in Azure Kubernetes Service clusters should be encrypted by customer-managed keys | Encrypting OS and data disks by using customer-managed keys provides more control and greater flexibility in key management. This requirement is common in many regulatory and industry compliance standards. | 2.0.0 | BuiltIn | Audit, Disabled | Link |
| Role-Based Access Control (RBAC) should be used on Kubernetes Services | To provide granular filtering on the actions that users can perform, use Role-Based Access Control (RBAC) to manage permissions in Kubernetes Service Clusters and configure relevant authorization policies. | 1.1.0 | BuiltIn | Audit, Disabled | Link |
| Azure Kubernetes Service Clusters should use managed identities | Use managed identities to wrap around service principals, simplify cluster management, and avoid the complexity required to manage service principals. Learn more at: https://aka.ms/aks-update-managed-identities | 1.0.1 | BuiltIn | Audit, Disabled | Link |
| Azure Kubernetes Service clusters should have Defender profile enabled | Microsoft Defender for Containers provides cloud-native Kubernetes security capabilities including environment hardening, workload protection, and run-time protection. When you enable the SecurityProfile.AzureDefender on your Azure Kubernetes Service cluster, an agent is deployed to your cluster to collect security event data. Learn more about Microsoft Defender for Containers in Defender for Containers. | 2.0.1 | BuiltIn | Audit, Disabled | Link |