This post is part of the Azure Spring Clean series being run by Joe Carlyle and Thomas Thornton, which is a monthly series focussing on Azure Management and best practice. Check out all the other articles at https://www.azurespringclean.com/.
Azure Policy has been around for a long while, allowing you to create policies that control what users can do in your subscriptions, mandate certain things and fix or alert when resources are out of compliance. If you want to learn more about Azure Policy and governance, in general, I recommend checking out this video from the Azure Advent Calendar and of course the rest of the articles in the Azure Spring Clean.
In this article, we are going to look closer at a new feature of Azure Policy that allows you to extend your policies into your Azure Kubernetes Service (AKS) clusters.
What is Azure Policy for AKS
Azure Policy is a new feature which allows you to extend Azure Policy beyond supporting just Azure resources and apply policies inside your AKS cluster as well.
Azure Policy for AKS builds on top of two open-source projects:
- Open Policy Agent providing the policy engine
- Gatekeeper providing the validating webhook to apply these policies
Using these projects, Kubernetes can validate all workloads as they are deployed into the cluster. If these resources don’t meet the requirements of the policies, then they are rejected.
Azure Policy for AKS sits on top of these two projects. It provides an interface for creating policies through the familiar Azure Policy interface, and reports on these policies in the Azure portal.
Before we delve too deep into this, it is worth being aware that Azure Policy for AKS is in preview currently, and because of that, it is only supporting built-in policies currently.
What is Azure Policy For?
Azure Policy for AKS extends the concept of Azure Policy into AKS. Using the familiar Azure Policy UI and language for writing policies, you can apply requirements and restrictions to workloads that run inside AKS.
As mentioned, the preview of Azure Policy for AKS only supports built-in policies. You can view these policies in policy definitions in the portal if you filter the list by “Kubernetes Service”. The current list of policies allows you to enforce some of the most common requirements for security in Kubernetes:
- Ensure containers and/or services listen only on allowed ports
- Enforce Labels on pods
- Enforce HTTPS ingress
- Ensure only allowed container images
- Do not allow privileged containers
- Ensure CPU and Memory limits are defined on all pods
- Enforce internal load balancers
- Enforce unique ingress hostnames across namespaces
Using Azure Policy for AKS
Now we know what it’s for, let’s take a look at how to set up and use Azure Policy for AKS. I’ve also published an Azure Snippets video looking at this process if you’d prefer to watch this.
As Azure Policy for AKS is in limited preview you need to sign up for this for specific subscriptions, you can do this here.
Once your subscription is onboarded, you need to deploy the policy components into your cluster. Deploying the policy service is done through the policy tab on the AKS cluster. Clicking on the “enabled add-on” button starts this process.
This should be all that is required to enable the add-on, but if you experience issues you may need to re-register some providers, details of this can be found here.
Enabling the add-on takes a while as it deploys the resources into your cluster. Once it completes, you will see an Azure Policy pod deployed into your kube-system namespace.
Applying a Policy
Now we have Azure Policy for AKS up and running we can look at applying a policy. For this example, we are going to create a policy that requires container images to come from a specific registry. This is a fairly common requirement to prevent the running of unauthorized containers in the cluster.
To apply this, we’ll go to the Azure Policy page and click on “definitions” to find the built-in policy we want to apply. If we filter by “Kubernetes Service” we can then find the policy called “Ensure only allowed container images in AKS”.
If we click on the policy we can then click the “assign” button we can configure assigning the policy, which allows us to define where the policy will be applied and how it will be applied. We can scope the application of the policy to management group, subscription or resource group. On this page, we can also provide any exclusions we want, a description of the assignment and enabling the policy.
On the next page, we define any parameters that are needed for the policy. In the case of this policy, we need to provide a regex parameter that defines what container images are allowed to be used. Here we want to ensure that we can only deploy images from a registry called “samcogan.azurecr.io” so we will use a regex of “^.+samcogan.azurecr.io/.+$”. We will also choose the effect of the policy, for AKS policies we have 2 options “EnforceRegoPolicy” to enforce the policy, or disabled.
This policy does not offer any remediation options, so we can skip the next tab and go ahead and create the policy.
The policy add-on running in AKS checks in with Azure Policy every 5 minutes, so we need to wait for that to happen and the policy be applied. Before that happens, the policy will be in a “not started” state.
Once the policy is applied, it will do two things.
For resources that are already deployed into AKS, we will get a report indicating whether they comply with the policy or not. This cluster has a large number of pods running not from this repo, so it shows not in compliance.
At this level, we see that the cluster as a whole is not compliant, but if we click on the cluster, we can get a more detailed report showing which containers are out of compliance.
Blocking New Resources
In addition to auditing compliance of existing resources, any new pods created on the cluster will need to pass the policy before they can be created. If we try to deploy a new workload, we will see that the requested deployments and replica sets get created, but no pods. If we describe the replica set, we can see the policy is blocking this.
The only way to can get containers to run is to deploy them from the “samcogan.azurecr.io” container registry.
Azure Policy for AKS provides a way to apply Gatekeeper polices to your cluster using the familiar Azure Policy interface, making your AKS clusters more secure and compliant. It also provides a way to report on the state of your AKS policies alongside your existing Azure policies for a single pane of glass.
Being in preview, the amount of policies you can apply is relatively limited, although they do cover some of the most common scenarios. As it moves into GA, I imagine we will see more policies and the ability to create your own using open policy agent.
Azure Spring Clean
That brings us to the end of this article, but I hope you will check out all the other articles available this month during Azure Spring Clean and take this opportunity to give your subscriptions a good clean!