Esta página se muestra en inglés. Una traducción al español está en curso.
SkillsApr 15, 2026·3 min de lectura

Open Policy Agent (OPA) — Unified Policy Engine for Cloud Native

CNCF graduated policy engine that decouples authorization and admission rules from your services. Write policies once in Rego, evaluate them anywhere.

Listo para agents

Instalación lista para agent

Este activo puede instalarse después de elegir el runtime, revisar el plan y ejecutar el comando correspondiente.

Native · 98/100Política: permitir
Superficie agent
Cualquier agent MCP/CLI
Tipo
Skill
Instalación
Single
Confianza
Confianza: Established
Entrada
OPA — Policy as Code for Cloud Native
Comando de instalación directa
npx -y tokrepo@latest install 4153bc1e-3900-11f1-9bc6-00163e2b0d79 --target codex

Ejecutar después de confirmar el plan con dry-run.

TL;DR
OPA decouples authorization policies from application code using the Rego language, evaluated anywhere from Kubernetes to microservices.
§01

What it is

Open Policy Agent (OPA) is a CNCF graduated project that provides a general-purpose policy engine. Instead of hardcoding authorization logic into each service, you write policies in Rego, a declarative language designed for structured data inspection. OPA evaluates those policies against JSON input and returns a decision.

OPA is used by platform engineers, DevOps teams, and security architects who need consistent policy enforcement across Kubernetes admission control, API authorization, Terraform plan validation, and CI/CD pipelines.

§02

How it saves time or tokens

Without OPA, every service implements its own authorization checks, leading to duplicated logic and inconsistent enforcement. OPA centralizes policies so a single Rego file can govern access across dozens of services. When a compliance rule changes, you update one policy instead of patching every service. This reduces both engineering time and the risk of policy drift.

§03

How to use

  1. Install OPA:
brew install opa
# or download from https://github.com/open-policy-agent/opa/releases
  1. Write a policy in Rego:
package authz

default allow = false

allow {
  input.method == "GET"
  input.path == "/public"
}

allow {
  input.user.role == "admin"
}
  1. Evaluate the policy against input:
opa eval -i input.json -d policy.rego 'data.authz.allow'
§04

Example

# Create input.json
cat > input.json << 'ENDJSON'
{
  "method": "GET",
  "path": "/public",
  "user": {"role": "viewer"}
}
ENDJSON

# Evaluate
opa eval -i input.json -d policy.rego 'data.authz.allow'
# Result: true (matches the GET /public rule)
§05

Related on TokRepo

§06

Common pitfalls

  • Writing imperative-style Rego instead of declarative rules. Rego is not a scripting language; each rule body is a set of conditions that must all be true.
  • Forgetting that OPA evaluates policies in memory. Loading very large datasets (millions of rows) into OPA data slows evaluation; use external data APIs for large lookups.
  • Not testing policies before deploying them. OPA has a built-in test framework (opa test) that should be part of your CI pipeline.

Preguntas frecuentes

What language does OPA use for policies?+

OPA uses Rego, a declarative query language designed for inspecting structured data like JSON. Rego policies define rules as logical conditions. The language supports set operations, comprehensions, and partial evaluation for complex authorization scenarios.

How does OPA integrate with Kubernetes?+

OPA integrates with Kubernetes through the Gatekeeper project, which runs as an admission controller. It intercepts resource creation and modification requests, evaluates them against Rego policies, and rejects requests that violate constraints like label requirements or resource limits.

Is OPA suitable for real-time API authorization?+

Yes. OPA evaluates policies in microseconds because it loads policies and data into memory. For API authorization, services send a JSON authorization request to OPA and receive an allow/deny decision. OPA handles thousands of decisions per second on a single instance.

Can OPA replace my existing RBAC system?+

OPA can implement RBAC, ABAC, and custom authorization models. You write the role-checking logic in Rego. However, OPA is a policy engine, not a user directory. You still need an identity provider to authenticate users and supply role claims to OPA.

What is the difference between OPA and Gatekeeper?+

OPA is the core policy engine that evaluates Rego policies against any JSON input. Gatekeeper is a Kubernetes-specific project built on OPA that provides CRDs for defining constraints and constraint templates, making it easier to manage policies in a Kubernetes-native way.

Referencias (3)
  • OPA GitHub— OPA is a CNCF graduated project for general-purpose policy evaluation
  • OPA Docs— Rego is a declarative language for structured data inspection
  • Gatekeeper GitHub— Gatekeeper provides Kubernetes-native CRDs for OPA policies

Discusión

Inicia sesión para unirte a la discusión.
Aún no hay comentarios. Sé el primero en compartir tus ideas.

Activos relacionados