Azure Policy for Kubernetes releases support for custom policy

Azure Policy and AKS teams are excited to announce the public preview of custom policy support for Azure Kubernetes Service (AKS) clusters!

 

With this feature is enabled, you can create and assign custom policy definitions and constraint templates to your AKS clusters. We are also rolling out some exciting enhancements to the AKS policy such as enhanced error state information for troubleshooting, definition schema changes to auto-generate constraints instead of requiring customer input, VS Code extension for Azure Policy update for easier authoring, and an embedded constraint template inside the policy definition to not have dependency on an external endpoint.

 

Let’s walk through the cool new features step-by-step! 

 

 Embed Your Constraint Template Using TemplateInfo  

 

 

 

 

 

 

"then": { 
        "effect": "[parameters('effect')]", 
        "details": { 
          "templateInfo": { 
            "sourceType": "PublicURL", 
            "url": https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml 
          } 
} 

 

 

 

 

 

 

Azure Policy is introducing a new property known as templateInfo that allows users to define the source type for the constraint template. By defining templateInfo in policy definitions, users  don’t have to define constraintTemplate or constraint properties. Users still need to define apiGroups and kinds — more on that below. TemplateInfo initially supports two ways to define the constraint template source type: Base64Encoded and PublicUrl. Base64Encoded format allows users to privately embed the constraint template within a policy definition.   

 

Learn more about templateInfo in our documentation.  

 

Generate Custom Policy Definitions Using Azure Policy’s Visual Studio Code Extension 

 

Users are encouraged to use the Azure Policy Visual Studio (VS) Code Extension to use this new capability and create their custom Microsoft.Kubernetes.Data definitions seamlessly. With the VS Code Extension, once a user provides any Open Policy Agent  (OPA) GateKeeper v3  constraint template, they can auto-generate their policy definition JSON file!   

 

Here’s how it works: 

1. Confirm you’ve installed the Azure Policy VS Code Extension.  

1. Open up the valid constraint template YAML file as you would to reference it in your policy definition. You need to have the YAML file open for the Command Palette to display the auto-generation  option. 

1. From the menu bar, go to  View > Command Palette, and enter  Azure Policy for Kubernetes: Create Policy Definition from Constraint Template. 

```````````````````````````` ````````

 

4. Select the appropriate  sourceType  value. This is where you can choose how you want your constraint template to be referenced in your policy definition — as a public URL or privately encoded within the policy definition using Embedded format. 

                                    

 

5. Let’s select the Base64Encoded (Embedded) option to check it out.  Once you select it, voilà! A new file opens up with your auto-generated policy definition. Make sure to fill in the  /* EDIT HERE */  portions of the policy definition JSON with actual values: 

Remember to take this completed policy definition JSON to the Azure portal or another supported SDK to create the policy definition within your Azure environment. 

 

Learn more about the Azure Policy VS Code Extension in our documentation. 

 

Defining API Groups & Kinds In Your Custom Definitions 

 

It’s important to note that with the new templateInfo property, users are expected to define apiGroups and kinds directly in their policy definitions since constraint and constraintTemplate properties are not used. 

 

Here’s a quick refresher of apiGroups and kinds: 

• apiGroups refers to the type of Kubernetes object that the constraint is applied to. You can learn more about apiGroups in the Kubernetes documentation.  
• kinds refers to the kind of Kubernetes objects the constraint is applied to, such as a “Pod”. You can learn more about kinds in the Kubernetes documentation.  

 

Users have seen these fields in a constraint file previously, like this:

 

Let’s go through a quick example!

 

We would like to create a custom policy definition that specifies that AKS clusters that follow a specific naming convention and only uses allowed images. We will use a constraint template from the Azure Policy library. 

 

We defined apiGroups as [“”]  because we chose to include the core apiGroup. 

 

We decided to specify “Pod” in the kinds property to limit constraint application to the pod level. 

 

Therefore, using the VS Code Extension to generate our Azure Policy custom policy definition and inputting the right values, the ‘then’ clause of our policy definition would look like this: 

 

 

"then": {
        "effect": "[parameters('effect')]",
        "details": {
          "templateInfo": {
            "sourceType": "PublicURL",
            "url": https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml
          },
          "excludedNamespaces": "[parameters('excludedNamespaces')]",
          "namespaces": "[parameters('namespaces')]",
          "values": {
            imageRegex: "^.+azurecr.io\/.+$",
            "excludedNamespaces": "[parameters('excludedNamespaces')]"
          },
          "apiGroups": [
            ""
          ],
          "kinds": [
            "Pod"
          ]
        }
      }

 

 

 

 

 

Let us know what you think of these additions to the Azure Policy experience in the comments below!