Skip to content

SYSTEM Cited by 2 sources

Open Policy Agent (OPA / Gatekeeper)

Open Policy Agent (OPA) is a CNCF-graduated general-purpose policy engine; Gatekeeper is the Kubernetes admission-controller integration built on top of it. Policies are written in Rego, a declarative logic-programming language, and evaluated against structured input (Kubernetes API requests, application requests, CI/CD metadata, …).

In the Kubernetes deployment model, Gatekeeper enforces policies on every CREATE / UPDATE admission — the cluster API server calls into Gatekeeper, Gatekeeper evaluates the policy set against the incoming object + live state, and either admits or rejects. This is patterns/policy-gate-on-provisioning in wiki terms: compliance at manifest-submission time, shift-left from post-hoc audit.

OPA's place in the policy-engine landscape

OPA / Rego vs Cedar / AVP vs AWS SCPs — three different policy engines, three slightly different niches:

Engine Language Primary enforcement layer Analyzability by design?
OPA / Gatekeeper Rego (Datalog-ish) K8s admission; also app auth Partial (general-purpose)
Cedar / AVP Cedar App-request time Yes (constrained-by-design)
AWS SCPs IAM policy JSON AWS Organizations (account-wide) Yes (SMT-proven via systems/aws-policy-interpreter)

All three are concepts/policy-as-data instances — policies in a store separate from code, versioned, audited.

Seen in

  • sources/2026-02-26-aws-santander-catalyst-platform-engineering — Santander Catalyst's policies catalog is "a central repository of policies ensuring compliance and security across all operations using Open Policy Agent" — the regulated-bank equivalent of ProGlove's SCP-based guardrails. Lives on the EKS control plane cluster alongside systems/crossplane (stacks catalog) and systems/argocd (data-plane claims).

  • sources/2026-01-12-aws-salesforce-karpenter-migration-1000-eks-clusters — Salesforce deploys OPA policies for proactive PDB validation at admission as the cluster-wide governance layer during their 1,000-cluster Karpenter migration. Canonical wiki instance of OPA used for operational correctness (preventing misconfigured PDBs from blocking node replacement) rather than security policy — expanding the wiki's view of what OPA is useful for.

  • — Zalando embeds OPA as a Go library inside Skipper to deliver concepts/authorization-as-a-service across their 15,000 Ingresses / 5,000 routegroups / up-to-2M-rps fleet. Canonical non-Gatekeeper wiki instance: OPA is used at ingress request time for per-request HTTP authorization, not at K8s admission time. Key structural contributions:

  • Embedded-library shape — no sidecar, no separate deployment; the policy engine shares the Skipper process address space.
  • Multi-tenant virtual instances — one logical OPA instance per referenced application inside each Skipper replica; memory reuse + grace-period GC against high-frequency route churn.
  • Policy bundles fetched from AWS S3, authored + published via Styra DAS. Direct instance of patterns/s3-as-policy-bundle-source-for-availability: the enforcement path depends only on S3, not on the DAS control plane.
  • Input-schema alignment with the upstream OPA Envoy plugin — patterns/align-with-upstream-plugin-input-schema applied so every upstream Rego example / doc / training works unchanged inside Skipper.
  • Bounded memory discipline across bundles, request-body parsing, decision logs, and status reports — patterns/bounded-telemetry-data-structures-for-policy-engine — because embedding couples OPA's OOM fate to the ingress's.
  • Two OTel span paths (per-decision + control-plane traffic) sent to Lightstep; decision IDs link back into Styra DAS decision-log UI.
  • Developer contract: one annotation opaAuthorizeRequest("my-application") on an Ingress; Rego bundle named after the application ID. Canonicalises patterns/ingress-layer-authorization-offload.
  • Explicit differentiation from the vanilla Envoy OPA plugin: "In a vanilla OPA deployment, you typically run one OPA process per application. Skipper … multiple virtual OPA instances to coexist within a single Skipper process deployment."

Deployment shapes on wiki

Deployment Enforcement point Wiki source
OPA Gatekeeper (admission controller) K8s API server admission Santander / Salesforce ingests
OPA embedded library in ingress (Skipper) HTTP request at ingress Zalando 2024-12-05 ingest
OPA-as-sidecar / ext-authz (Envoy) HTTP request at mesh/proxy Referenced as upstream alignment target

Rego semantics, partial evaluation, constraint templates, and Gatekeeper mutation remain out of scope until a future source drills into them; bundle distribution is now canonicalised via concepts/policy-bundle + the Zalando S3-source topology.

Last updated · 542 distilled / 1,571 read