---
title: Open Policy Agent (OPA) — Policy decoupling for API authorization
source_type: official-doc
url: https://www.openpolicyagent.org/docs/latest/
archive_url:
related_projects: [ca-tmpl]
related_branches: [feature-security-operational-baseline, feature-repository-access-permission-contract, feature-tenant-context-policy]
tags: [ca-security, authorization, opa, rego, policy-engine, cncf, official-doc]
status: raw
confidence: high
created: 2026-05-22
last_reviewed: 2026-05-27
---

# Open Policy Agent (OPA) — Policy Engine

> Layer: `raw/official-docs/` — OPA 공식 docs landing 페이지 verbatim.
> ca-tmpl baseline (Spring Security in-process authorization) 의 **외부 정책 엔진 대안** 으로서 OPA 의 핵심 정의 (policy engine + decoupling + Rego) 의 1차 근거.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-security-operational-baseline]] | ca-tmpl baseline 의 authorization 전략으로 OPA 외부 엔진 분리를 채택하지 않은 결정의 비교군. "decouples policy decision-making from enforcement" 의 trade-off (latency / operational complexity vs hot-reload) 가 채택 시점 기준의 근거 |
| [[raw/branch-notes/feature-repository-access-permission-contract]] | repository-level access control 정책이 단순 (`AUTHZ_INSUFFICIENT_PERMISSION` 1종) → in-process baseline 으로 충분, OPA 도입 미루는 근거 |
| [[raw/branch-notes/feature-tenant-context-policy]] | tenant 격리 정책이 declarative 화가 필요해질 때 OPA Rego 의 후보 자격 검토 근거 |

## 컨텍스트

ca-tmpl baseline 은 Spring Security 기반 in-process authorization 을 가정. OPA 는 정책을 외부 엔진/사이드카로 분리하는 **대안적 authorization 아키텍처**. baseline 이 OPA 를 채택하지 않은 이유와 채택 시점 기준을 명확히 하기 위함.

## 출처 / Source

- 원본 URL: https://www.openpolicyagent.org/docs/latest/
- 아카이브 URL: (미수집)
- 저자 / 조직: Open Policy Agent (CNCF Graduated Project)
- 발행일: rolling docs
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim)

> [§What is OPA?] "The Open Policy Agent (OPA, pronounced 'oh-pa') is an open source, general-purpose policy engine that unifies policy enforcement across the stack."

> [§What is OPA?] "OPA decouples policy decision-making from policy enforcement."

> [§Writing Policy with Rego] "OPA policies are expressed in a high-level declarative language called Rego."

> [§What is OPA?] "You can use OPA to enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more."

> [§What is OPA?] "OPA is proud to be a graduated Cloud Native Computing Foundation (CNCF) project"

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| OPA-C1 | OPA 는 open source, general-purpose policy engine 으로 stack 전반의 policy enforcement 를 통일 | [§What is OPA?] "The Open Policy Agent (OPA, pronounced 'oh-pa') is an open source, general-purpose policy engine that unifies policy enforcement across the stack." | `official-vendor-doc` | OPA 의 자체 정의 (CNCF 프로젝트 landing page) | OPA 가 모든 application authorization 시나리오에서 in-process 솔루션보다 우월하다는 뜻 아님 |
| OPA-C2 | OPA 는 policy decision-making 과 policy enforcement 를 decouple 한다 | [§What is OPA?] "OPA decouples policy decision-making from policy enforcement." | `official-vendor-doc` | PEP/PDP 분리 아키텍처 평가 | decouple 의 latency 비용 / sidecar 운영 복잡도는 본 인용 범위 밖 |
| OPA-C3 | OPA 정책은 Rego 라는 high-level declarative language 로 표현 | [§Writing Policy with Rego] "OPA policies are expressed in a high-level declarative language called Rego." | `official-vendor-doc` | OPA 정책 작성 | Rego 의 정확한 syntax / 학습 곡선 / Spring SpEL 과의 표현력 비교는 본 인용 범위 밖 |
| OPA-C4 | OPA 의 적용 영역: microservices, Kubernetes, CI/CD pipelines, API gateways, "and more" | [§What is OPA?] "You can use OPA to enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more." | `official-vendor-doc` | OPA 의 범용 use case 범위 | 각 영역에서 OPA 가 가장 적합하다는 뜻 아님 — 단지 적용 가능 카테고리 |
| OPA-C5 | OPA 는 CNCF 의 graduated project (최고 단계 maturity) | [§What is OPA?] "OPA is proud to be a graduated Cloud Native Computing Foundation (CNCF) project" | `official-vendor-doc` | OPA 의 governance / maturity 신뢰성 평가 | graduated 단계가 production-ready 임을 보장한다는 뜻 아님 — CNCF maturity model 의 형식적 단계 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `OPA-C1`: OPA 의 정체성 (general-purpose policy engine)
  - `OPA-C2`: 핵심 design principle — policy decision/enforcement decoupling
  - `OPA-C3`: Rego 가 declarative language 라는 사실
  - `OPA-C4`: 적용 가능한 use case 카테고리 5가지
  - `OPA-C5`: CNCF graduated 단계 (governance maturity)
- **이 자료가 증명하지 않는 것**:
  - PEP (Policy Enforcement Point) / PDP (Policy Decision Point) 의 정확한 정의 — 본 페이지 직접 인용에는 없음 (별도 OPA architecture 페이지 또는 XACML 표준 참조)
  - Spring Security `@PreAuthorize` 와의 정량적 latency / hot-reload 비교
  - OPA sidecar pattern 의 정확한 배포 절차 (별도 deployment 페이지)
  - Rego 의 정확한 syntax 와 학습 cost
  - ca-tmpl 의 단순 권한 모델이 OPA hot-reload 이점을 못 누린다는 정량 판단
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - OPA query latency 의 실측치 (sidecar HTTP REST API vs gRPC / WASM bundle)
  - Rego policy bundle 의 versioning / rollback 절차
  - Spring Security `@PreAuthorize` 의 정책 변경 시 hot-reload 가능 옵션 (Spring Cloud Config refresh 등) 의 정확한 한계
  - ca-tmpl 의 권한 모델이 다언어 microservice 환경으로 확장되는 시점 (= OPA 채택 기준)

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

- **PEP/PDP 분리** (개념 — 본 페이지 직접 인용 아님, XACML 표준 어휘):
  - PEP (Policy Enforcement Point) = application/sidecar 에서 OPA query 수행.
  - PDP (Policy Decision Point) = OPA 엔진이 Rego 정책 평가.
  - ca-tmpl baseline 은 Spring Security `@PreAuthorize` / `SecurityFilterChain` 이 PEP+PDP 둘 다 in-process 로 수행.
- **vs Spring Security in-process** (ca-tmpl baseline) — 해석:
  - Spring Security: 정책 = Java/SpEL/method annotation. 배포 단위 = JAR.
  - OPA: 정책 = Rego 파일 (`OPA-C3`). 배포 단위 = OPA bundle (별도 lifecycle).
  - 정책 변경 시 OPA 는 application 재배포 불필요 (decouple — `OPA-C2`), Spring Security 는 코드 변경 + 재배포.
- **ca-tmpl 이 채택하지 않은 이유 (추정 — UNSUPPORTED_DECISION, 본 자료가 직접 증명 안 함)**:
  - skeleton 단계의 권한 모델이 단순 (`AUTHZ_INSUFFICIENT_PERMISSION`, `AUTHZ_TENANT_MISMATCH` 2종).
  - 정책 변경 빈도 낮음 → OPA 의 hot-reload 이점이 미미.
  - operational complexity 증가 (OPA sidecar 운영, Rego 학습 cost).
- **언제 OPA 가 baseline 이 되는가 (추정)**:
  - 정책이 자주 바뀌고 비개발자 (보안팀/규제팀) 가 정책을 작성해야 할 때.
  - 다언어 (polyglot) microservice 환경에서 정책 통일이 필요할 때 (`OPA-C1`/`OPA-C4` 의 "stack 전반 통일" 측면과 부합).
  - Kubernetes admission control 등 횡단 정책 (`OPA-C4` 의 use case 카테고리에 포함).
- **장점 (해석)**:
  - 정책-코드 분리 (`OPA-C2`) → 정책 변경이 배포에서 독립.
  - Rego 는 declarative + testable (`OPA-C3` 의 "high-level declarative" 측면).
- **단점 (UNSUPPORTED — 본 페이지 직접 인용에 없음, 일반적 운영 지식)**:
  - latency 추가 (OPA query); sidecar 호출 비용.
  - Rego 는 별도 학습 곡선.
  - 정책 저장소 (OPA bundle server) 운영 부담.

## Related / 관련

- 같은 주제 다른 official-doc:
  - (관련 OPA 페이지 — OPA Gatekeeper, Rego language guide 별도 fetch 필요 시)
- 인용하는 branch:
  - [[raw/branch-notes/feature-security-operational-baseline]]
  - [[raw/branch-notes/feature-repository-access-permission-contract]]
  - [[raw/branch-notes/feature-tenant-context-policy]]
- canonical contract 섹션 (예정):
  - [[raw/project-notes/ca-skeleton-operational-contract]] (예정, "정책 엔진 분리 검토 시점" 메모 — Security Operational Baseline 영역)
- 대안 그룹: **Group G-B — Security baseline**
- 본 source 의 위치: **대안 5 — OPA policy engine** (PEP/PDP 분리)
- 인용하는 wiki: (미작성)