Skip to content

SYSTEM Cited by 3 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 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 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 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 — 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 — 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 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."

  • sources/2026-09-24-zalando-agentic-platform-open-sourcing-the-agentic-identity-broker — OPA integrated into agentgateway via the Envoy Envoy external-processing (ExtProc) extension point to authorize individual agent tool calls. Zalando reuses its existing OPA investment (connected to enterprise access management) as the fine-grained layer above the broker's coarse token exchange: "both broker exchange policy and gateway tool-call policy must permit a request" — the out-of-band policy shape applied to agent tool calls. The same ExtProc extension will enforce central tool approvals independent of where the agent runs. Second wiki instance of OPA at request time via ExtProc/Envoy (after the Skipper embedded-library shape), here in an agent/MCP gateway rather than an ingress.

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 via ExtProc in AI/MCP gateway (agentgateway) Agent tool-call request Zalando 2026-09-24 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 policy-bundle + the Zalando S3-source topology.

  • concepts/policy-as-data — OPA's Rego policies in a central catalog are one realization of the concept
  • policy-gate-on-provisioning — the admission-time enforcement pattern Gatekeeper embodies
  • systems/cedar — constrained-by-design alternative for analyzable app-level authz
  • service-control-policy — AWS Organizations' account-scoped guardrail layer
  • systems/kubernetes — the substrate Gatekeeper plugs into
  • systems/skipper-proxy — host proxy of the Zalando embedded- library deployment
  • systems/rego — OPA's policy language
  • systems/styra-das — commercial OPA control plane
  • authorization-as-a-service — user-facing shape of the Skipper integration
  • embedded-opa-library-in-proxy — the deployment model
  • virtual-opa-instance-per-application — multi-tenancy inside the proxy process
  • policy-bundle — OPA's distribution artifact
  • embedded-opa-in-proxy
  • virtual-policy-instance-per-application
  • s3-as-policy-bundle-source-for-availability
  • ingress-layer-authorization-offload
  • align-with-upstream-plugin-input-schema
  • bounded-telemetry-data-structures-for-policy-engine
Last updated · 766 distilled / 2,225 read