Night-shift charts keep deploying privileged pods and hostPath volumes on AKS. How should the security engineer enforce Kubernetes guardrails without writing a custom admission-controller manifest?
Select an answer to reveal the explanation.
Short Explanation
Stop shipping home-grown admission YAML for every chart. Flip on the Azure Policy add-on for AKS and assign the built-in Kubernetes policies—no privileged pods, resource limits required.
Full Explanation
The Azure Policy add-on for AKS plus built-in Kubernetes policies (for example deny privileged containers and require resource limits) enforces guardrails at admission time without each night-shift chart owner maintaining custom admission-controller YAML. That is the platform way to stop privileged pods and hostPath sprawl on the canal cluster while staying inside Azure Policy governance.
Handing operators a complete ValidatingAdmissionWebhook manifest to maintain per namespace fails by operational and exam concept: custom webhooks are possible but not the “without writing a custom admission-controller manifest” answer. Exporting a custom initiative JSON and applying it only at management-group root without the AKS add-on fails because Kubernetes policies need the AKS policy add-on to evaluate cluster resources effectively. A subscription Deny assignment on Microsoft.ContainerService that disables deployments entirely is a blunt Azure RBAC hammer; it does not encode Kubernetes pod-security guardrails and breaks legitimate releases.
Exam caveat: Azure Policy for Kubernetes is not the same as only assigning Azure RBAC on the AKS resource—the add-on brings policy into the cluster admission path. Operational check: enable the add-on, assign deny-privileged and resource-limits policies, deploy a privileged test pod, and confirm it is denied while a compliant pod succeeds.