Microsoft Defender for Containers UX unreliability while using policy initiatives for auto-provisioning

Microsoft Defender for containers is a great product to easily add security to your AKS clusters and Azure Container Registries (ACR), both within your Azure infrastructure and for on-premises Kubernetes deployments and using Amazon EKS. The product offers you various container security solutions, which can be switched on and off in a relatively simple manner. A few if the added values you can think of are vulnerability assessments, threat protection and environment hardening.

In addition to enabling the defender plan within Microsoft Defender for Cloud, it is also advisable to use the auto-provisioning functionality. If you have a single subscription, you often see that this is still done manually via the GUI (within the Azure portal). But if you have multiple subscriptions, perhaps management groups, or if you no longer require configurations to be done manually via the GUI, you will soon find yourself using Azure Policy.

The great thing about Azure policy is that you can set up all the desired configurations in 1 central location, and then apply them at-scale to the desired scope. Whether these are subscriptions or management groups.

The moment you turn on the auto-provisioning settings of Microsoft Defender for Containers manually in the GUI, Azure Policy is also used in the background to apply the configuration. This means that you can easily use this mechanism for all auto provisioning configurations and you are therefore completely free of the manual configuration in the GUI.

The auto-provisioning settings of Microsoft Defender for Containers consist of 2 flavors: 

• Component: Which part of the functionality do you want to deploy:
  • Defender Deamonset
  • Azure Policy for Kubernetes

• The scope of the deployment:
  • Azure resources
  • Resources running outside Azure, leveraging Azure Arc

If you want to enable both components, for resources within Azure and running outside Azure, you have a total of 4 options. There is already a Microsoft-built (builtin) Azure Policy for each of these capabilities:

If you deploy all these policies to your desired scope (for example your subscription), you will see that the GUI detects this and automatically checks the boxes for the auto-provisioning components:

If you use Azure Policy more often, the amount of policy assignments – which the above configuration entails – may make you decide to neatly place the policy definitions in an Initiative. Which basically means that you can bundle multiple policies into a group and then assign them all together. For example, in the scenario above you do not have 4, but 1 single assignment: that of the initiative.

What’s going wrong?

As a fanatical Azure Policy user, I have therefore also chosen to replace the 4 policy definitions for enabling the auto-provisioning settings associated with Microsoft Defender for Containers with a single policy initiative.

The auto-provisioning is done nicely on the relevant resources, so I thought “finished”. Until I checked the GUI of Microsoft Defender for Cloud. Where I noticed that the checkmarks of the auto-provisioning components were both set to “Off”. I checked the entire configuration again and finally found out that the initiative assignment is not detected at all (although being functional). While this is a valid method to apply governance over your configurations. It is even recommended in larger environments or when using Azure Policy on a massive scale.

Although I’m not a fan of Microsoft support calls, I reported this bug. Not because I don’t know about this, but there are plenty of customers who would be confused by this.
After all the product group came up with the following answer:

It’s a known limitation and we will add this update in the documents soon.

At the time of writing this article, this “known limitation” cannot yet be found in the documentation. So if you run into this issue, you’re informed 😉 .