8.8 KiB
8.8 KiB
title, source_type, url, archive_url, related_projects, related_branches, tags, status, confidence, created, last_reviewed
| title | source_type | url | archive_url | related_projects | related_branches | tags | status | confidence | created | last_reviewed | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Open Policy Agent (OPA) — Policy decoupling for API authorization | official-doc | https://www.openpolicyagent.org/docs/latest/ |
|
|
|
raw | high | 2026-05-22 | 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 decouplingOPA-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_MISMATCH2종). - 정책 변경 빈도 낮음 → OPA 의 hot-reload 이점이 미미.
- operational complexity 증가 (OPA sidecar 운영, Rego 학습 cost).
- skeleton 단계의 권한 모델이 단순 (
- 언제 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:
- 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: (미작성)