Skip to main content

More Info:

Advisory: an admission controller (Pod Security Admission, Kyverno, or OPA Gatekeeper) should enforce workload best practices at admission time, not only detect them after the fact.

Risk Level

Medium

Address

Security

Compliance Standards

  • Cloudanix Best Practice

Triage and Remediation

Remediation

Manual Steps

  1. Decide your admission enforcement approach (design choice)
    • Choose one primary mechanism to enforce workload policy cluster‑wide:
      • Azure Policy for Kubernetes (OPA Gatekeeper) – recommended in AKS for broad policy-as-code.
      • Pod Security Admission (PSA) – for baseline/restricted pod security controls.
      • Kyverno – if your org standardizes on Kyverno and you are prepared to manage it yourself.
    • Define which CIS C1–C5 practices you want enforced (e.g., no privileged pods, runAsNonRoot, read-only root FS, restricted capabilities, proper ServiceAccount use).
  2. Check if Azure Policy / Gatekeeper is enabled and enforcing (any machine with Azure CLI access)
    • List policy assignments on the AKS cluster’s resource group and subscription (replace the IDs with real values):
    • In the Azure Portal, open the AKS cluster → Policies blade and review:
      • Whether Azure Policy Add-on for Kubernetes is Enabled.
      • Which Kubernetes policy definitions (Gatekeeper constraints) are Deny vs Audit.
    • If the add-on is disabled or policies are only in Audit/non-blocking mode, plan to enable it and switch critical policies to Deny where operationally acceptable.
  3. Review Pod Security Admission configuration (any machine with Azure CLI access)
    • Get AKS cluster config and inspect the API server profile for PSA settings:
    • In the Portal, under the AKS cluster Settings → Policies → Pod Security, review:
      • The Pod Security level (e.g., baseline/restricted) and enforcement mode (Enforce vs Audit).
    • If PSA is disabled or only auditing, decide whether to enable baseline or restricted and set it to Enforce (with appropriate exception strategy for sensitive namespaces).
  4. Map policies to CIS C1–C5 and identify gaps (design + portal/CLI review)
    • For C1–C5 requirements you care about (e.g., disallow hostPath, privileged, hostNetwork, missing resource limits, non-root user, dropped capabilities):
      • Verify there is at least one active enforcement mechanism for each requirement:
        • Azure Policy / Gatekeeper constraint in Deny mode, or
        • PSA level (baseline/restricted) covering that behavior, or
        • Kyverno policy in enforce/block mode.
    • Document gaps where policies exist only in Audit, or not at all.
  5. Adjust configuration to enforce (Portal / Azure CLI / your IaC only)
    • Using Azure Portal or your chosen IaC (ARM/Bicep/Terraform):
      • Enable the Azure Policy Add-on for Kubernetes on the AKS cluster if not enabled.
      • Assign or update Kubernetes policy definitions so that high‑risk CIS C1–C5 controls are configured with effect Deny, not just Audit.
      • In Pod Security settings, enable and enforce an appropriate level (baseline or restricted) for all or selected namespaces.
    • If using Kyverno via IaC, ensure:
      • Kyverno is installed as an add-on or via your deployment tooling.
      • Relevant ClusterPolicy/Policy objects are configured with validationFailureAction: Enforce.
  6. Verify admission enforcement is active (any machine with kubectl access)
    • Retrieve a kubeconfig for the AKS cluster if you don’t have one:
    • Attempt to create a clearly non-compliant pod (e.g., privileged, hostPath) and confirm it is rejected at admission:
    • Verify the command fails with an error message from Azure Policy / Gatekeeper, Pod Security Admission, or Kyverno. If it succeeds, revisit Steps 2–5 to tighten enforcement.
kubectl cannot configure admission policy engines or AKS control-plane features; this must be done in the Azure portal, Azure CLI, or your IaC (ARM/Bicep/Terraform) definitions for the AKS cluster. Refer to the Manual Steps section for guidance on enabling and configuring Pod Security Admission, Kyverno, or Gatekeeper at the cluster/control-plane level.
What output indicates a problem
  • PSA section: many or all workload namespaces appear under “Namespaces without PSA enforce labels”.
  • Kyverno section: no kyverno deployment and/or no ClusterPolicies/Policies with validationFailureAction=enforce and validate rules.
  • Gatekeeper section: no gatekeeper-system deployment and/or no ConstraintTemplates and Constraints.
If all three mechanisms above are effectively absent or only configured in audit/detect mode, the cluster fails this control and requires a design decision and implementation to introduce an enforcing admission policy engine via AKS configuration/IaC.