Files

T

DongHyeonka 6c53ded9cb init: llm-wiki-haness 하네스 설계

2026-07-24 14:21:35 +09:00

11 KiB

Raw Blame History

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed

title

source_type

url

archive_url

status

confidence

Istio Security — Sidecar PEP for management endpoints

Layer: raw/official-docs/ — Istio 공식 "Security" concept page verbatim 발췌. ca-tmpl baseline (feature-management-actuator-security-contract) 의 "Spring 단 management port + network ACL" 결정에 대한 service-mesh 대안 근거.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-management-actuator-security-contract	ca-tmpl baseline 이 mesh-agnostic 으로 선택한 이유의 비교 근거 — Istio sidecar PEP 가 application 책임을 platform 책임으로 옮기는 대안
raw/branch-notes/feature-security-operational-baseline	mTLS 대안 cross-link — Istio PeerAuthentication STRICT 가 application-level cert 관리 대안

컨텍스트 / 왜 저장했는지

feature-management-actuator-security-contract ca-tmpl baseline 은 Spring 단에서 management port + network ACL 을 default 로 결정. service mesh 환경에서는 application 이 아니라 sidecar 가 management traffic 을 가르는 패턴이 가능. 대안으로 검토하고 baseline 이 mesh 를 가정하지 않은 이유를 분명히 함.

출처 / Source

원본 URL: https://istio.io/latest/docs/concepts/security/
아카이브 URL: (미수집)
저자 / 조직: Istio (CNCF 프로젝트)
발행일: 지속적으로 갱신 (latest channel)
관련 CRD: PeerAuthentication, AuthorizationPolicy, RequestAuthentication
마지막 확인일: 2026-05-27

핵심 인용 / Key quotes (verbatim, 2026-05-27 확인)

[§Peer/Request Authentication, 2026-05-27 verified] "Peer and request authentication policies are stored separately by kind, PeerAuthentication and RequestAuthentication respectively."

[§Policy Enforcement Points, 2026-05-27 verified] "Sidecar and perimeter proxies work as Policy Enforcement Points (PEPs) to secure communication between clients and servers."

[§Identity model, 2026-05-27 verified] "The Istio identity model uses the first-class service identity to determine the identity of a request's origin."

[§AuthorizationPolicy, 2026-05-27 verified] "To configure an authorization policy, you create an [AuthorizationPolicy custom resource]...An authorization policy includes a selector, an action, and a list of rules."

[§Certificate rotation, 2026-05-27 verified] "Istio agent monitors the expiration of the workload certificate. The above process repeats periodically for certificate and key rotation."

[§PeerAuthentication mTLS modes, 2026-05-27 verified] "PERMISSIVE: Workloads accept both mutual TLS and plain text traffic...STRICT: Workloads only accept mutual TLS traffic...DISABLE: Mutual TLS is disabled."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
ISTIO-SEC-C1	Istio 의 sidecar 와 perimeter proxy 는 client ↔ server 통신 보안을 강제하는 Policy Enforcement Point (PEP) 로 동작한다	[§Policy Enforcement Points, 2026-05-27 verified] "Sidecar and perimeter proxies work as Policy Enforcement Points (PEPs) to secure communication between clients and servers."	`official-standard`	mesh 가 활성화된 Kubernetes workload	sidecar PEP 가 `/actuator/*` 같은 특정 path 를 외부 트래픽으로부터 거부한다는 직접 명시는 없음 — path 기반 거부는 별도 AuthorizationPolicy 규칙으로 구성해야 함
ISTIO-SEC-C2	`PeerAuthentication` 과 `RequestAuthentication` 은 별도 CRD kind 로 저장되며 각각 peer (service-to-service) / request (end-user JWT) 인증 정책을 표현	[§Peer/Request Authentication, 2026-05-27 verified] "Peer and request authentication policies are stored separately by kind, `PeerAuthentication` and `RequestAuthentication` respectively."	`official-standard`	Istio CRD-기반 인증 구성	한 workload 가 동시에 두 정책 모두 가져야 한다는 뜻 아님 — 별도 선택 가능
ISTIO-SEC-C3	Istio identity 모델은 first-class `service identity` 를 사용해 요청 origin 의 identity 를 결정한다	[§Identity model, 2026-05-27 verified] "The Istio identity model uses the first-class `service identity` to determine the identity of a request's origin."	`official-standard`	service-to-service 인증 정책 의사결정	`service identity` 가 IP 기반 ACL 보다 항상 안전하다는 직접 비교는 본 인용에 없음 — 단지 identity model 의 기본 단위
ISTIO-SEC-C4	`AuthorizationPolicy` 는 selector + action + rules 목록 구조의 custom resource 로 인가 정책을 표현	[§AuthorizationPolicy, 2026-05-27 verified] "To configure an authorization policy, you create an [`AuthorizationPolicy` custom resource]...An authorization policy includes a selector, an action, and a list of rules."	`official-standard`	모든 mesh workload 에 적용 가능한 인가 정책 정의	rule 의 정확한 field schema (예: `to.operation.paths`) 는 본 인용에 명시 없음 — 별도 reference page
ISTIO-SEC-C5	Istio agent 는 workload certificate expiration 을 monitor 하며 위 발급 프로세스가 주기적으로 반복되어 cert/key rotation 이 자동화된다	[§Certificate rotation, 2026-05-27 verified] "Istio agent monitors the expiration of the workload certificate. The above process repeats periodically for certificate and key rotation."	`official-standard`	mesh-enrolled workload 의 mTLS cert 운영	rotation 주기의 정확한 default 값 (예: 24h) 은 본 인용에 명시 없음 — 별도 install reference
ISTIO-SEC-C6	`PeerAuthentication` 의 mTLS 모드는 PERMISSIVE (mTLS + plain text 둘 다 수락), STRICT (mTLS 만 수락), DISABLE (mTLS 비활성) 3가지	[§PeerAuthentication mTLS modes, 2026-05-27 verified] "PERMISSIVE: Workloads accept both mutual TLS and plain text traffic...STRICT: Workloads only accept mutual TLS traffic...DISABLE: Mutual TLS is disabled."	`official-standard`	mesh 단계적 도입 (PERMISSIVE → STRICT 마이그레이션)	UNSET (정책 미설정) 의 fallback 동작이 어떤 mode 와 동일한지는 본 인용에 명시 없음

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- ISTIO-SEC-C1: sidecar/perimeter proxy 가 PEP 라는 공식 표준 정의 — service mesh 환경에서 application 이 아닌 mesh 가 인증 enforcement 책임을 가질 수 있음
- ISTIO-SEC-C2~C4: Istio 의 정책 CRD 분리 (peer/request 인증 + 인가), service identity 모델, AuthorizationPolicy 구조
- ISTIO-SEC-C5: Istio agent 의 자동 cert rotation (application code 변경 없이 mTLS 적용 가능)
- ISTIO-SEC-C6: STRICT/PERMISSIVE/DISABLE 3 모드 (단계적 도입 경로 명문화)
이 자료가 증명하지 않는 것:
- "Istio sidecar 만으로 /actuator/* 경로를 외부에 deny 한다" 는 직접 인용 부재 — path-level 거부는 별도 AuthorizationPolicy rule (to.operation.paths 필드) 작성 필요 (별도 reference page 확인)
- mesh sidecar 가 ca-tmpl 의 "separate management port + network ACL" 보다 항상 우월하다는 비교 — 본 자료는 mesh 환경 가정 문서이며, mesh-agnostic baseline 과의 정량 비교는 부재
- sidecar latency 정확한 수치 (보통 수 ms 라는 운영 관행은 별도 perf 벤치마크 필요)
- cert rotation 의 default 주기 (예: 24h) — 본 인용은 "periodically" 만 명시
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl skeleton 이 K8s + Istio mesh 를 baseline 으로 가정해도 되는가 — 본 자료는 mesh 가정 시의 옵션 set 만 보여줌
- AuthorizationPolicy 로 /actuator/* path 거부 규칙의 정확한 YAML 형식 (별도 reference page)
- PeerAuthentication STRICT 적용 시 기존 plain HTTP probe (Spring Boot Actuator health check 등) 와의 호환성

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

본 섹션은 자료 직접 인용 아님. ca-tmpl baseline 비교 컨텍스트 해석.

service mesh 시나리오의 management endpoint 보호 (가설 / 추가 검증 필요):
- PeerAuthentication (STRICT mTLS) + AuthorizationPolicy (deny external to /actuator/*) 조합 가능 — 단, /actuator/* path 거부의 정확한 YAML 은 별도 reference 확인
- sidecar 가 PEP → application 은 endpoint 보호 책임에서 자유로움 (ISTIO-SEC-C1 의 추론 확장)
- cert rotation 은 Istio agent 자동 (ISTIO-SEC-C5)
vs ca-tmpl baseline (separate port + network ACL):
- ca-tmpl: skeleton 이 mesh-agnostic → application 자체 책임으로 가짐
- mesh 가 있으면 baseline 이 sidecar 정책으로 옮겨갈 수 있음 (단 mesh 도입 전제)
결정 권고 (조건부):
- ca-tmpl baseline 은 "minimum viable" → mesh 없이도 동작 (mesh 무의존 보존)
- mesh 도입 환경에서는 application 의 management port 를 ClusterIP-only 로 두고 sidecar 로 한 번 더 차단 (defense-in-depth)
장점 (mesh 측):
- certificate-based service identity → IP 기반 ACL 의 한계 극복 (ISTIO-SEC-C3)
- 자동 cert rotation (ISTIO-SEC-C5)
- 정책 수정이 application 재배포와 분리 (ISTIO-SEC-C4 CRD 모델)
단점:
- mesh control plane 운영 부담 (본 자료 범위 밖, 운영 관행)
- sidecar latency (수 ms — 본 자료 범위 밖, perf 벤치마크 필요)
- mesh 미도입 환경에서는 사용 불가 → skeleton baseline 으로 가정 불가
ca-tmpl 이 mesh 를 baseline 으로 채택하지 않은 이유 (추정):
- skeleton 은 platform 중립 → Kubernetes + mesh 가정은 너무 강한 전제
- mesh sidecar 정책은 platform team 의 SSOT 이 되어야 하며 application contract 와 책임 분리가 필요

적용 branch-note:
- raw/branch-notes/feature-management-actuator-security-contract
- raw/branch-notes/feature-security-operational-baseline (mTLS 대안 cross-link)
canonical contract 섹션:
- raw/project-notes/ca-skeleton-operational-contract#Management / Actuator Security (예정)
대안 그룹: Group G-B — Actuator sub-topic
본 source 의 위치: 대안 4 — service mesh sidecar (Istio)

11 KiB Raw Blame History