Support admission controller mutations as to comply with Azure Policy

[MarkTopping]

I'd like to request/suggest a feature whereby Azure Policy (or similar) can modify inbound K8s manifests as to satisfy admission controller policies.

The primary rational and example I can give for requesting this is driven by the SecurityContext sections for Pod and Container specs. In a company which has a strong security posture we require these sections of the deployment manifest to be present. The settings within this section are largely the concern of our Operations team; but the deployment manifests are managed by the application development teams which by enlarge to not understand the settings within and (arguably) should not have to lay their eyes upon them. 99% of the time we certainly don't want them to change them. Yet without the correct SecurityContext settings their deployments will fail so it places a burden upon them.

If Azure Policies could be used to mutate/enrich inbound deployment manifests then we could omit the SecurityContext settings from the many deployment manifests, make life easier for application teams & help them to fall into the pit of success; and control the settings centrally and from a single location.

I'm sure there would be other use cases for such behavior such as injecting a private image repository url, default resource limits, required annotations, env vars for things like Proxy settings.

Apologies if I've missed a previous request for similar or completely misunderstood what can be achieved. More than happy to be educated if I can achieve this functionality already.

Thanks

[ghost]

Hi MarkTopping, AKS bot here :wave: Thank you for posting on the AKS Repo, I'll do my best to get a kind human from the AKS team to assist you.

I might be just a bot, but I'm told my suggestions are normally quite good, as such: 1) If this case is urgent, please open a Support Request so that our 24/7 support team may help you faster. 2) Please abide by the AKS repo Guidelines and Code of Conduct. 3) If you're having an issue, could it be described on the AKS Troubleshooting guides or AKS Diagnostics? 4) Make sure your subscribed to the AKS Release Notes to keep up to date with all that's new on AKS. 5) Make sure there isn't a duplicate of this issue already reported. If there is, feel free to close this one and '+1' the existing issue. 6) If you have a question, do take a look at our AKS FAQ. We place the most common ones there!

[ghost]

Triage required from @Azure/aks-pm

[ghost]

Action required from @Azure/aks-pm

[ghost]

@az-policy-kube would you be able to assist?

Issue Details

---

I'd like to request/suggest a feature whereby Azure Policy (or similar) can modify inbound K8s manifests as to satisfy admission controller policies. The primary rational and example I can give for requesting this is driven by the SecurityContext sections for Pod and Container specs. In a company which has a strong security posture we require these sections of the deployment manifest to be present. The settings within this section are largely the concern of our Operations team; but the deployment manifests are managed by the application development teams which by enlarge to not understand the settings within and (arguably) should not have to lay their eyes upon them. 99% of the time we certainly don't want them to change them. Yet without the correct SecurityContext settings their deployments will fail so it places a burden upon them. If Azure Policies could be used to mutate/enrich inbound deployment manifests then we could omit the SecurityContext settings from the many deployment manifests, make life easier for application teams & help them to fall into the pit of success; and control the settings centrally and from a single location. I'm sure there would be other use cases for such behavior such as injecting a private image repository url, default resource limits, required annotations, env vars for things like Proxy settings. Apologies if I've missed a previous request for similar or completely misunderstood what can be achieved. More than happy to be educated if I can achieve this functionality already. Thanks

Author:	MarkTopping
Assignees:	-
Labels:	`feature-request`, `triage`, `azure/policy`, `addon/policy`, `action-required`, `Needs Attention :wave:`
Milestone:	-

[ghost]

@sozercan, @ritazh would you be able to assist?

Issue Details

---

I'd like to request/suggest a feature whereby Azure Policy (or similar) can modify inbound K8s manifests as to satisfy admission controller policies. The primary rational and example I can give for requesting this is driven by the SecurityContext sections for Pod and Container specs. In a company which has a strong security posture we require these sections of the deployment manifest to be present. The settings within this section are largely the concern of our Operations team; but the deployment manifests are managed by the application development teams which by enlarge to not understand the settings within and (arguably) should not have to lay their eyes upon them. 99% of the time we certainly don't want them to change them. Yet without the correct SecurityContext settings their deployments will fail so it places a burden upon them. If Azure Policies could be used to mutate/enrich inbound deployment manifests then we could omit the SecurityContext settings from the many deployment manifests, make life easier for application teams & help them to fall into the pit of success; and control the settings centrally and from a single location. I'm sure there would be other use cases for such behavior such as injecting a private image repository url, default resource limits, required annotations, env vars for things like Proxy settings. Apologies if I've missed a previous request for similar or completely misunderstood what can be achieved. More than happy to be educated if I can achieve this functionality already. Thanks

Author:	MarkTopping
Assignees:	-
Labels:	`feature-request`, `azure/policy`, `addon/policy`, `upstream/gatekeeper`
Milestone:	-

[somejfn]

If I can add a comment on how this becomes important for runtime security, for many cluster operators the combination of POD security policies (PSPs) and Gatekeeper were a win. Use a default PSP to mutate pods so we can enforce a set of safe defaults in each pod security context (ie. set a default seccomp profile and explicit drop of all linux capabilities). Then use OPA Gatekeeper for validating admission control for things like labels and resource requests enforcement.

Now with PSPs being deprecated and their replacement lacking mutation support, Gatekeeper allowing mutating rules can become a complete solution for PSP's deprecation.

[miwithro]

@MarkTopping @somejfn we have example use cases here: Mutation | Gatekeeper (open-policy-agent.github.io) and gatekeeper-library/mutation/pod-security-policy at master · open-policy-agent/gatekeeper-library (github.com). We are looking to add the requested capabilities to our Custom Policy set on AKS.

[krupakar1329]

@miwithro Expected date of availability for this feature?

[ericsuhong]

@miwithro Any update on this feature? We would like to be able to modify deployments using Azure Policy enabled AKS clusters. However, gatekeeper installed via add-on doesn't seem to support this feature yet.

[nehakulkarni123]

@ericsuhong can you please email policypm@microsoft.com so we can understand your scenario and get you onboarded?

[ericsuhong]

@nehakulkarni123 @anlandu contacted me offline via Teams, and we discussed offline. Unfortunately, the current timeline doesn't align with us (we must be in all environments as soon as possible), but the feature looks promising!

[theadzik]

Can we know what is the current timeline for this? We need to use Mutation on our clusters. Can we enable public-preview on our clusters somehow?

[nehakulkarni123]

Hi all-- we're estimating public preview for mutation support on your AKS clusters by the end of this calendar year!

The functionality is out now in a limited preview state-- email me at nehakulkarni@microsoft.com, and we'll get you onboarded to the experience!

@theadzik @krupakar1329 @somejfn @MarkTopping

[nehakulkarni123]

Hi all-- excited to share that Azure Policy for Kubernetes support for mutation is in public preview. Read more here: https://techcommunity.microsoft.com/t5/azure-governance-and-management/remediate-your-azure-kubernetes-service-clusters-at-scale-using/ba-p/3974506

We look forward to your feedback!

FYI-- @theadzik @krupakar1329 @somejfn @MarkTopping @vyadh @hakabo @infbase @kxs-jnadeau @flbla @fnkr

[charleswool]

Update, ETA for Azure Policy for Kubernetes support for mutation to GA is Jan 2025