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 admission controller strategy (design choice)
    • On any machine with gcloud, list cluster details and note Kubernetes version and whether Autopilot is used:
    • Decide whether to:
      • Use built‑in Pod Security Admission (PSA) profiles (recommended baseline: restricted), and/or
      • Deploy a policy engine (Kyverno or Gatekeeper) via Terraform/Deployment Manager.
  2. Review Pod Security Admission (PSA) configuration (if using PSA)
    • On any machine with gcloud, check if a default Pod Security profile is set at cluster level (only via GKE APIs/IaC; this will often be unset):
      (GKE currently has no dedicated top‑level PSA field; you must enforce PSA via namespace labels or policy engine.)
    • On any machine with kubectl access, list namespaces and their PSA labels to see if restrictive profiles are enforced at admission:
    • If critical namespaces (application namespaces, not kube-system) lack enforce=restricted (or at least baseline), plan to manage these labels via Terraform/Deployment Manager (not kubectl for long‑term drift‑free config).
  3. Assess whether a policy engine (Kyverno / Gatekeeper) is already in use
    • On any machine with kubectl access, check for controllers and policies (discovery only; final config should be via IaC):
    • If no Kyverno/Gatekeeper controllers or policies exist, you currently do not have an admission policy engine enforcing workload best practices.
  4. Map existing/desired policies to best practices C1–C5
    • On any machine with kubectl access, inspect at least a sample of current policies for enforcement vs. audit:
    • Manually compare what’s enforced to the C1–C5 topics (e.g., non‑root, minimal capabilities, resource limits, disallow hostPath/privileged, require secure probes/config).
    • Decide which of these should be block‑on‑admission vs. audit only, and document that decision for implementation in your IaC (Terraform/Deployment Manager modules or GKE fleet policy if applicable).
  5. Implement or strengthen admission enforcement via GKE‑appropriate IaC/controls
    • If using PSA: define standard namespace labels for your environments in Terraform/Deployment Manager (example conceptual snippet for Terraform, not a direct command):
    • If using Kyverno or Gatekeeper: use Helm/Terraform/Config Sync to install the controller and define policies/constraints that enforce the C1–C5 rules (e.g., deny privileged pods, require resource limits). Ensure policies use deny/enforce modes, not just audit.
    • For Autopilot clusters, prefer PSA labels and Gatekeeper policies integrated via Config Sync/fleet‑level policy.
  6. Verify enforcement is active, not just detection
    • On any machine with kubectl access, attempt to create a workload that intentionally violates your intended policy (e.g., privileged pod without resource limits):
    • Confirm that the request is rejected at admission time with an error from PSA/Kyverno/Gatekeeper (HTTP 4xx and a message referencing the policy/PodSecurity) instead of being created successfully. If it is allowed, revisit steps 2–5 to tighten enforcement.
kubectl cannot configure admission policy engines or GKE control‑plane features; those are managed via the Google Cloud console, gcloud CLI, or your IaC definitions. Review the Manual Steps section for how to enable and configure Pod Security Admission or a third‑party admission controller (Kyverno or Gatekeeper) at the cloud provider level.