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.
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.