Azure Policy for AKS

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

Azure Policy for Azure Kubernetes Service (AKS) clusters now utilizes/extends Gatekeeper v3 (OPA). The overview, installation steps for the Azure Policy add-on, limitations and recommendations are documented here - https://aka.ms/kubepolicydoc
- --- - --- -
In this article,  the need and advantages of using the Azure Policy add-on for AKS will be highlighted  and guidance given on how to look  beyond a few limitations that exist at the moment.


First off, I am depicting the 3 Gatekeeper pods in the following image - which are  utilized after the Azure Policy add-on has been enabled for an AKS cluster - reiterating the utilization of  Gatekeeper.

GateKeeper_Pods.PNG

 

Advantage and Necessity for using the  Azure Policy add-on 

1. By installing / enabling  the Azure Policy add-on customers can gain the inherent benefits of utilizing a managed add-on - the most important benefit being that  - they would not need to resort to any manual upgrades if/when there is a version upgrade of Gatekeeper itself.

2. Azure Security Center actually requires the add-on to audit and enforce security capabilities and compliance inside your clusters.

 

Limitations 
However, at present there are a few limitations. Let us focus on 2  limitations from the present list -
1.Installations of Gatekeeper outside of the Azure Policy Add-on aren't supported. Uninstall any components installed by a previous Gatekeeper installation before enabling the Azure Policy Add-on.
2. Only built-in policy definitions are supported.

This means that the customer would not be able to utilize custom policies - considering - only built-in policies are supported + the usage of the add-on precludes any native Gatekeeper installation/usage.

 

Looking beyond limitations - 
So, for customers requiring policies beyond the existing  list of built-in policies, the overarching guidance is to use a combination of preventive and detective measures to achieve the same objective as their intended custom policies.
As an example - one of the customers wanted to take the policy driven route to ensure that the [default] namespace usage is always prohibited. At the time of this writing - it is not a built-in policy - so a preventive measure this customer could take is utilize Kubernetes native capabilities / RBAC as part of their deployment pipeline not allowing objects to be created in the [default] namespace.
Essentially, a preventive process enhancement to achieve their original objective.

The Azure Policy add-on is an advantage-laden route  to take  -
1. Utilize  the set of built-in Kubernetes policies as applicable
2. and combine them with preventive + detective measures to achieve  any custom policy intent - that may not exist today.

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.