llm-wiki/raw/official-docs/actuator-istio-sidecar-management-alt.md

---
title: Istio Security — Sidecar PEP & AuthorizationPolicy (management endpoint 대안)
source_type: official-doc
url: https://istio.io/latest/docs/concepts/security/
archive_url:
status: raw
confidence: high
tags: [ca-actuator, istio, service-mesh, sidecar, peer-authentication, mtls, official-doc]
related_projects: [ca-skeleton-operational-contract]
related_branches: [feature-management-actuator-security-contract, feature-security-operational-baseline]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# 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](https://csrc.nist.gov/glossary/term/policy_enforcement_point) (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](https://csrc.nist.gov/glossary/term/policy_enforcement_point) (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 와 책임 분리가 필요

## Related / 관련

- 적용 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)**