Skip to main content

Technical Enforcement of Runtime Policies with OPA and Kyverno

🌟 Objective​

Ensure that containers that do not meet the minimum security requirements defined by the organisation cannot be executed, through formal and automatic enforcement mechanisms, namely in Kubernetes and CI/CD pipelines.

The policies described in this chapter do not decide whether a container is acceptable.
They prevent manifestly non-compliant executions, providing a technical blocking mechanism that supports - but does not replace - governance and human decision.

This file defines how to use OPA, Kyverno and equivalent mechanisms as technical guardrails, not as a risk authority.

🧬 What execution policies are (in the SbD-ToE model)​

Execution policies are formal rules evaluated automatically at the moment a workload is created. In the SbD-ToE model, they serve to:

  • Block known insecure configurations;
  • Impose non-negotiable minimum requirements;
  • Produce objective evidence of non-compliance;
  • Reduce the margin of operational error in automated environments.

🔒 A policy never grants authorisation - it only refuses the absence of minimum requirements.

Risk acceptance, the granting of exceptions and promotion between environments are always explicit human decisions, handled outside the policy mechanism.

⚠️ Enforcement is not risk acceptance​

A common conceptual error is to assume that:

  • workload approved by policy = secure workload
  • execution allowed = risk accepted

In SbD-ToE, this equivalence is explicitly prohibited.

Policies:

  • validate objective minimum conditions;
  • do not assess context, impact or residual risk;
  • do not replace analysis or accountability.

An execution may:

  • comply with all policies,
  • be technically correct,
  • and still not be acceptable for a given context (e.g. PROD, sensitive data, L3).

📘 Recommended tools and mechanisms​

ToolTechnical functionRole in SbD-ToE
OPA (Gatekeeper)Evaluation of Rego rules at admission timeTechnical blocking
KyvernoDeclarative policies in YAMLBlocking and controlled mutation
Admission WebhooksCustom validationSpecific enforcement
CI/CD validatorsEarly checks (e.g. OPA, Checkov, Semgrep)Reduction of failures before runtime

These tools produce binary technical decisions (allow / deny) - not risk decisions.

🛠️ How to apply policies correctly​

1️⃣ Define non-negotiable minimum requirements​

Typical examples:

  • Execution as a non-root user;
  • Prohibition of privileged containers;
  • Use of images from authorised registries;
  • Signature verification (integrity);
  • Application of a minimum securityContext.

These requirements must be:

  • clear,
  • objective,
  • technically verifiable.

2️⃣ Implement policies as code​

  • Use Rego (OPA) or YAML (Kyverno);
  • Version them in Git, alongside the infrastructure;
  • Apply them via GitOps;
  • Associate each policy with an explicit organisational requirement.

3️⃣ Test and apply progressive enforcement​

  • Start in audit mode;
  • Analyse rejections and false positives;
  • Communicate the rules to the teams;
  • Activate enforce only after validation.

The aim is to reduce error, not to create opaque blockages.

📂 Where to keep policies and how to govern them​

  • Dedicated Git repository (policies/);
  • Versioning and change history;
  • Differentiated application per environment;
  • Immutable logs of rejections and compliant executions;
  • Formal process for temporary exceptions.

Any exception outside the policy must be:

  • explicitly approved;
  • time-limited;
  • traceable.

🔍 Relation to human decision​

In the SbD-ToE model:

  • Policies block what is objectively insecure;
  • People decide what is acceptable.

This separation ensures:

  • clear accountability;
  • real auditability;
  • prevention of implicit trust induced by automation.

Without this distinction, the policy becomes an undue substitute for governance.

✅ Good practices​

  • Treat policies as guardrails, not as a seal of approval;
  • Keep policies simple, objective and justified;
  • Clearly separate:
    • technical enforcement,
    • risk decision,
    • formal exception;
  • Review policies after incidents or platform changes;
  • Document the rationale for each rule applied.

📎 Cross-references​

DocumentRelation to enforcement
01-imagens-base.mdBlocking of unapproved images
03-assinatura-cadeia-trust.mdIntegrity verification as evidence
04-hardening-containers.mdEnforcement of minimum restrictions
09-riscos-processo-imagens.mdSeparation between signal, blocking and decision
15-aplicacao-lifecycle.mdOperational integration into the lifecycle

🧩 Policies are technical limits, not trust decisions.
When a policy decides on people's behalf, governance has already failed.