Secure your Azure Kubernetes Service (AKS) clusters with Azure Policy
Article
You can apply and enforce built-in security policies on your Azure Kubernetes Service (AKS) clusters using Azure Policy. Azure Policy helps enforce organizational standards and assess compliance at-scale. After you install the Azure Policy add-on for AKS, you can apply individual policy definitions or groups of policy definitions called initiatives (sometimes called policysets) to your cluster. See Azure Policy built-in definitions for AKS for a complete list of AKS policy and initiative definitions.
This article shows you how to apply policy definitions to your cluster and verify those assignments are being enforced.
Prerequisites
This article assumes you have an existing AKS cluster. If you need an AKS cluster, you can create one using Azure CLI, Azure PowerShell, or Azure portal.
You can apply a policy definition or initiative in the Azure portal using the following steps:
Navigate to the Azure Policy service in Azure portal called Policy.
In the left pane of the Azure Policy page, select Definitions.
Under Categories, select Kubernetes.
Choose the policy definition or initiative you want to apply. For this example, select the Kubernetes cluster pod security baseline standards for Linux-based workloads initiative.
Select Assign.
Set the Scope to the resource group of the AKS cluster with the Azure Policy add-on enabled.
Select the Parameters page and update the Effect from audit to deny to block new deployments violating the baseline initiative. You can also add extra namespaces to exclude from evaluation. For this example, keep the default values.
Select Review + create > Create to submit the policy assignment.
Create and assign a custom policy definition
Custom policies allow you to define rules for using Azure. For example, you can enforce the following types of rules:
Security practices
Cost management
Organization-specific rules (like naming or locations)
Azure Policy now utilizes a new property known as templateInfo that allows you to define the source type for the constraint template. When you define templateInfo in policy definitions, you don’t have to define constraintTemplate or constraint properties. You still need to define apiGroups and kinds. For more information on this, see Understanding Azure Policy effects.
Once you create your custom policy definition, see Assign a policy definition for a step-by-step walkthrough of assigning the policy to your Kubernetes cluster.
Validate an Azure Policy is running
Confirm the policy assignments are applied to your cluster using the following kubectl get command.
Let's first test what happens when you schedule a pod with the security context of privileged: true. This security context escalates the pod's privileges. The initiative disallows privileged pods, so the request is denied, which results in the deployment being rejected.
Create a file named nginx-privileged.yaml and paste in the following YAML manifest.
Create the pod using the kubectl apply command and specify the name of your YAML manifest.
kubectl apply -f nginx-privileged.yaml
As expected, the pod fails to be scheduled, as shown in the following example output:
Error from server ([denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}): error when creating "privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}
The pod doesn't reach the scheduling stage, so there are no resources to delete before you move on.
Test creation of an unprivileged pod
In the previous example, the container image automatically tried to use root to bind NGINX to port 80. The policy initiative denies this request, so the pod fails to start. Now, let's try running that same NGINX pod without privileged access.
Create a file named nginx-unprivileged.yaml and paste in the following YAML manifest.
Your output should be similar to the following example output, which shows the pod is successfully scheduled and has a status of Running:
NAME READY STATUS RESTARTS AGE
nginx-unprivileged 1/1 Running 0 18s
This example shows the baseline initiative affecting only the deployments that violate policies in the collection. Allowed deployments continue to function.
Delete the NGINX unprivileged pod using the kubectl delete command and specify the name of your YAML manifest.
kubectl delete -f nginx-unprivileged.yaml
Disable a policy or initiative
You can remove the baseline initiative in the Azure portal using the following steps:
Navigate to the Policy pane on the Azure portal.
Select Assignments.
Select the ... button next to the Kubernetes cluster pod security baseline standards for Linux-based workload initiative.
Select Delete assignment.
Next steps
For more information about how Azure Policy works, see the following articles:
The source for this content can be found on GitHub, where you can also create and review issues and pull requests. For more information, see our contributor guide.
Azure Kubernetes Service feedback
Azure Kubernetes Service is an open source project. Select a link to provide feedback:
Use Azure Policy to enforce policies and safeguards on your Kubernetes clusters at scale. Azure Policy Ensures that your cluster is secure, compliant, and consistent across your organization.
Demonstrate the skills needed to implement security controls, maintain an organization’s security posture, and identify and remediate security vulnerabilities.