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
MediumAddress
SecurityCompliance Standards
- Cloudanix Best Practice
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify how the cluster is provisioned (console vs. IaC)
- On any machine with access to your OCI tenancy, determine whether OKE clusters are managed via Terraform/Resource Manager, OCI CLI, or manually in the OCI Console.
- If using Terraform/Resource Manager, locate the codebase that defines your OKE clusters and note any modules related to “gatekeeper”, “kyverno”, or “psa/pod-security”.
-
Check for an admission policy engine deployed to the cluster
- On any machine with
kubectlaccess (this is read-only discovery; remediation will be in console/CLI/IaC): - Interpretation:
- Presence of
gatekeeper-systemorkyvernonamespaces and matching webhook configurations indicates OPA Gatekeeper or Kyverno is installed. pod-security.kubernetes.io/enforcelabels on namespaces indicate Pod Security Admission (PSA) is being used to enforce baseline/restricted policies.
- Presence of
- On any machine with
-
Review current enforcement scope and strength
- Still on a
kubectl-enabled machine, inspect policies to see if they cover the benchmark’s workload best practices (C1–C5) and are set to enforce (not only audit): - Manually compare existing constraints/policies/PSA levels to your required C1–C5 workload controls (e.g., run-as-nonroot, privileged/hostNetwork restrictions, image registry controls, resource limits).
- Still on a
-
Decide on the admission strategy and update configuration via OCI Console/CLI/IaC
- If no enforcement engine exists, or current policies are only auditing/not aligned with C1–C5:
- Choose one primary mechanism for enforcement:
- Enable and standardize Pod Security Admission via namespace labels (for baseline/restricted pods), and/or
- Deploy and manage OPA Gatekeeper or Kyverno using your standard provisioning path (Terraform module, Helm chart invoked by Terraform or OCI DevOps, or manual setup documented in your OKE runbooks).
- Choose one primary mechanism for enforcement:
- Apply changes through your chosen control-plane management surface (Terraform/OCI Resource Manager templates or documented OCI Console procedure). Do not make ad‑hoc kubectl changes if your organization mandates IaC.
- If no enforcement engine exists, or current policies are only auditing/not aligned with C1–C5:
-
Verify enforcement is active (not just audit)
- On a
kubectl-enabled machine, attempt to create a known-bad workload that violates one of your C1–C5 rules (for example, privileged pod without required labels): - Confirm that the request is rejected with an error message from PSA, Gatekeeper, or Kyverno, and that it is not merely recorded in audit logs while still allowing creation.
- On a
-
Document and standardize the configuration for future clusters
- In your OCI/OKE provisioning pipeline (Terraform modules, OCI Resource Manager stacks, or standard console build runbooks), add explicit steps/variables to:
- Always deploy and configure the chosen admission controller(s).
- Apply default namespace PSA labels and/or default Gatekeeper/Kyverno policies for C1–C5.
- Keep this documentation with your OKE cluster standard so future clusters automatically enforce workload policy at admission.
- In your OCI/OKE provisioning pipeline (Terraform modules, OCI Resource Manager stacks, or standard console build runbooks), add explicit steps/variables to:
Using kubectl
Using kubectl
kubectl cannot configure or enable admission policy engines on Oracle OKE, because this is managed in the OKE control plane via the OCI Console, OCI CLI, or IaC (Terraform/Resource Manager). To plan and implement enforcement with Pod Security Admission, Kyverno, or OPA Gatekeeper, follow the guidance in the Manual Steps section instead.
Automation
Automation

