Istio mTLS 내부 동작 원리 - istiod가 인증서(Cert) 발급·배포·갱신하는 방법

istiod가 인증서(Cert) 발급·배포·갱신하는 방법

1. 각 요소의 역할

istio-agent (pilot-agent): 파드 안에서 개인키 생성 → CSR 작성·전송 →(서명된) 인증서 수령 → Envoy에 제공까지 담당. 만료 시점도 모니터링
istiod (내장 CA 포함): CSR(서명요청) 검증·서명, Mesh 전반의 신뢰(anchor) 관리
Envoy(사이드카): SDS(Secret Discovery Service) 로 agent에게서 인증서/개인키를 받아 mTLS에 사용

2. 발급(issuance): 누가 키를 만들고, 누가 서명?

1️⃣ 파드 내에서 istio-agent가 개인키와 CSR을 생성

2️⃣ ìstio-agent는 CSR을 자신의 자격증명과 함께 istiod에 제출 (istiod는 CSR을 받는 gRPC 서비스를 노출)

3️⃣ istiod(내장 CA) 가 CSR의 자격증명을 검증해 워크로드 인증서를 서명

istiod가 CA gRPC 서비스(gRPC over TLS 포트 15012) 를 열어 두고 있습니다.
istiod는 Istio Certificate Service 라는 gRPC API를 갖고 있고, 대표 RPC가 CreateCertificate 입니다.
istio-agent가 그 엔드포인트로 CSR을 보내면 이 메서드가 CSR을 입력으로 받아 서명된 인증서를 반환합니다.

3. 배포(distribution): Envoy가 인증서를 받는 방법

4️⃣ Envoy → agent(SDS 경로): Envoy는 같은 파드의 istio-agent에게 SDS API로 인증서/개인키를 요청

5️⃣ agent → Envoy(SDS 경로): agent는 istiod로부터 받은 인증서와 자신이 보관한 개인키를 Envoy에 SDS로 전달

흐름 정리

istio-agent(pilot-agent)가 개인키를 만들고 gRPC(TLS)로 CSR을 istiod에 보내 서명된 인증서를 받음
그 인증서/키를 SDS(UDS)로 Envoy에 제공
SDS 경로 차단 금지: Pod 보안 정책/네트워크 정책으로 Envoy↔agent UDS/SDS 흐름을 방해하지 않도록 주의

4. 갱신(rotation): 자동으로 언제, 어떻게 갱신?

6️⃣ istio-agent가 인증서 만료를 모니터링하고, 기한이 다가오면 동일한 절차(CSR→서명→SDS)를 주기적으로 반복해 인증서/키를 교체

istio-agent가 만료를 트리거로 CSR 재요청→배포를 반복
TTL과 그에 대한 여유 비율(grace period ratio) 로 언제 갱신을 시작할지를 미리 계산
istio-agent가 현재 인증서의 남은 유효기간을 모니터링하고, 남은 시간이 TTL × SECRET_GRACE_PERIOD_RATIO 이하로 떨어지면 CSR→서명→SDS 공급을 수행(기본 SECRET_TTL=24h, SECRET_GRACE_PERIOD_RATIO=0.5, 지터 0.01) -> 기본값 기준으로 만료 12시간 전쯤 갱신이 걸림
고정 시간이 아니라, TTL/만료 시점을 기준으로 한 예약 갱신
워크로드 내부 mTLS 인증서는 istio-agent가 만료를 감시해 자동 회전하므로, 대시보드/알림은 “SDS 갱신이 제때 일어나는가(정지/실패 탐지)”와 “외부 노출 인증서의 만료 임박”을 중심으로 두는 게 현실적

5. 요약 diagram

[Pod]
  └─ istio-agent: (1)개인키 생성 → (2)CSR 작성·istiod로 전송
       └─ istiod(CA): (3)CSR 검증·서명, cert 반환
            └─ Envoy: (4)SDS(UDS)로 agent에 cert/키 요청
                 └─ istio-agent: (5)서명된 cert + 개인키를 Envoy에 SDS로 제공
                      └─ Envoy: cert/키 사용해 mTLS 수행
[만료 임박]
  └─ istio-agent: (6)만료 감시 → (2)~(5) 반복 (자동 로테이션)

6. 설계 운영상의 이점

이점	설명	효과/영향
보안경계 최소화	개인키를 파드 내부(istio-agent) 에서 생성·보관하고 Envoy로만 전달 → 외부 노출 경로 차단	키 유출 위험 감소, 규정 준수 강화
투명성	앱 코드 수정 없이 사이드카 + agent 가 인증서 전주기를 처리	개발팀 영향 최소화, mTLS 온보딩 가속
대규모 자동화	CSR 생성→서명→SDS 배포→만료 감시·교체까지 자동 파이프라인	운영 오버헤드↓, 갱신 실패/휴먼 에러↓, 일관성↑

⭐️ 결론

Istio는 agent–istiod–Envoy 삼자 구조와 SDS를 통해, 키 생성(파드 내부) → CSR/서명(istiod CA) → Envoy 배포(SDS) → 만료 감시·자동 로테이션을 표준 절차로 수행

(선택) 기업 PKI·체인 연동

기본은 istiod 내장 CA 이지만, 실무에서는 오프라인 루트 → 클러스터별 중간 CA → istiod 형태로 조직 PKI 체인을 구성해 운영

1. 기업 PKI?

구분	퍼블릭 PKI	기업(프라이빗) PKI
신뢰 앵커	브라우저/OS 기본 탑재 루트	조직이 배포한 사내 루트
누가 신뢰?	전 세계 일반 사용자	사내/지정 파트너 등 배포 받은 대상만
주 사용처	인터넷 공개 HTTPS	내부 mTLS, VPN, 단말/서비스 인증

2. 왜 기업 PKI 체인을 쓰나?

루트 키 보호와 거버넌스: 루트는 오프라인/HSM(Hardware Security Module, 암호키 전용 보안 하드웨어)에 두고 중간 CA만 서명해 운영 리스크 최소화 -> 개인키를 장치 내부에서 생성·보관하고, 서명/복호화 같은 연산도 장치 안에서만 수행해 키가 밖으로 빠져나오지 않게 함
컴플라이언스·감사: CA 권한과 범위를 정책(CP/CPS)으로 제한(경로 길이, EKU, 이름 제약 등)
멀티클러스터/하이브리드: 여러 클러스터·플랫폼이 하나의 신뢰 루트로 통합되어 상호 mTLS가 쉬워짐.

3. 두 가지 운영 패턴

1️⃣ 기본(내장 CA)

istiod(자체 루트) ──→ 워크로드(Envoy)

빠르고 단순(학습/개발/소규모)
엔터프라이즈 PKI와의 표준화·감사 요건은 약함

2️⃣ 기업 PKI 연동(권장)

오프라인 Root CA ──(서명)──> 조직/클러스터 Intermediate CA ──(서명)
──> istiod(발급 CA) ──(서명)──> 워크로드(Envoy)

Root CA: 루트 개인키를 오프라인(HSM)에 저장하여 완전 신뢰
Intermediate CA: 온라인 운영(조직 공용 또는 클러스터별). 권한·경로 길이 제한
istiod: 발급 CA로 워크로드 인증서를 서명(레플리카 여러 개라도 같은 CA 한 개로 동작)
End Entity: Envoy가 받는 워크로드 인증서

4. Root CA를 두는 이유

신뢰의 시작점 -> 자체서명 루트 인증서를 갖고 아래 단계(중간 CA) 에 서명·권한 위임
보안상 루트 키는 오프라인/HSM에 보관하고, 실서비스 인증서는 중간 CA가 발급
중간 CA에 경로 길이(pathLen), EKU, 이름 제약(Name Constraints) 같은 정책/범위 제한을 걸어 정책을 강제
체인 교체 시 크로스사인 등으로 무중단 전환을 설계하고, 필요하면 폐지(CRL)·상태(OCSP) 체계를 통해 신뢰를 관리

5. Intermeiate CA

루트가 서명한 하위 CA(중간 CA) -> 인증서에 CA:TRUE가 설정되어 있고, 아래 단계(다른 하위 CA나 최종 인증서) 를 서명할 권한이 있음
보통 온라인으로 운영(필요하면 HSM 사용)하며, 루트의 권한을 ‘제한된 범위’로 위임받음
워크로드 CSR 서명은 istiod, ìntermeiate CA는 환경/조직/리전별 분리를 위한 계층

[오프라인 Root CA]
    └─(서명)→ [조직/도메인용 Intermediate CA]
                  └─(서명)→ [istiod (발급 CA)]
                        └─(서명)→ [워크로드 인증서(Envoy)]

Intermediate CA 수평적 분리: 같은 루트를 공유하지만 영역/목적별로 분리 가능(e.g. Prod / Dev / Test 별, Region 별, 사업부/라인 별, 클러스터 그룹 별)
- 보안/리스크 분리: 한 중간 CA 키가 유출돼도 그 도메인(예: Prod/Region/클러스터)만 영향을 받음
- 정책 분리: Prod/Dev, 사업부, 리전별로 다른 만료기간·KeyUsage·감사 요건을 적용 가능
- 운영·교체 용이성: 중간 CA만 교체해도 워크로드 재발급이 자연스럽게 이어져 무중단 롤오버가 쉬움

Root
 ├─ Org-Prod-ICA ──┬→ istiod(prod-cluster-a) → Workloads
 │                  └→ istiod(prod-cluster-b) → Workloads
 └─ Org-Dev-ICA  ───→ istiod(dev-cluster)    → Workloads

Intermediate CA 수직적 분리: 정책/조직 경계를 한 단계 더 둠 (e.g. Root → Org-ICA → Region-ICA → istiod(issuing) → Workload)
- 장점: 상위/하위 책임과 권한을 더 세밀히 분리(예: 글로벌 정책 CA → 지역 운영 CA → 클러스터 발급자)
- 주의: 체인 깊이는 짧게 유지(RFC 5280/클라이언트 한계 고려, 보통 루트 포함 3~4단계 내)

6. 발급·검증이 실제로 도는 방식(연동 시)

[1] 루트 → 중간 (오프라인 루트가 서명, 범위/경로 제한)
[Offline Root CA] ──(sign)──▶ [Intermediate CA(s): Org/Cluster/Region]

[2] 중간 → istiod (발급 CA)
[Intermediate CA] ──(sign)──▶ [istiod (Issuing CA; 키는 클러스터 내부 보관)]

[3] 발급 경로 (워크로드 CSR)
[istio-agent (Pod)]
     ──(gRPC/TLS :15012, CSR)──▶ [istiod CA]
     ◀──(Signed leaf cert + chain)──

[4] 배포 경로 (SDS/UDS)
[Envoy sidecar] ──(SDS 요청, UDS)──▶ [istio-agent]
[istio-agent]   ──(SDS 응답: cert+key)──▶ [Envoy]

[5] mTLS 검증
Peer A: (leaf + chain) ⇆ Peer B: (leaf + chain)
        └─ chain: 리프(Envoy) cert + intermediate CA cert(들)
        └─ chain을 [Trust Bundle의 Root(s)]까지 검증

[6] Trust Bundle 배포
[Trust Bundle: 상대가 보낸 인증서 체인을 검증할 때, 내 쪽 Envoy가 들고 있는 루트 목록]
   ├─ 루트 CA 공개 인증서 세트를 Envoy에 사전 배포/갱신
   └─ 메쉬 전역 배포: istiod가 SDS로 배포 or Kubernetes ClusterTrustBundle 사용
- 루트는 Trust Bundle로 유지, 중간은 보통 서버가 체인에 포함해 전송
- 메시의 모든 Envoy가 같은 루트 세트를 신뢰해야 상호 mTLS가 성립

7. mTLS 플로우

사전조건
  - Envoy A/B는 이미 istio-agent(SDS)로부터 cert/개인키를 받았고, 
  - 메시에 배포된 Trust Bundle(루트 CA들)을 로컬에 보유

흐름(텍스트 다이어그램)

App A           Envoy A (client)                          Envoy B (server)           App B
│ 1) 요청 ─────────▶ │                                     │                           │
│                  │ 2) TLS ClientHello ─────────────────▶ │                           │
│                  │ ◀─ 3) ServerHello + ServerCert(+CertRequest:mTLS) ─────────────── │
│                  │ 4) 서버 인증서 검증(로컬 Trust Bundle로 체인 검증 + SAN/SPIFFE 매칭) │
│                  │ 5) ClientCert + CertificateVerify ──▶ │                           │
│                  │                                       │ 6) 클라이언트 인증서 검증(체인+SPIFFE/SAN) │
│                  │ ◀────── 7) Finished 교환 / 세션 키 합의(대칭키) ───────────────▶ │
│                  │────────────── 8) (mTLS 채널 성립: Envoy A ⇄ Envoy B 암호화) ───────────────│
│ 9) 평문 요청 ───▶ │ 10) 암호화된 HTTP/gRPC 전송 ───────▶ │ ── 11) 평문 전달 ────────▶ │
│ ◀────────────── 12) 암호화된 응답 ◀──────────────────── │ ◀──────── 평문 응답 ─────── │

보충 설명
- 2~7: 핸드셰이크 단계에서 서버 인증(항상), mTLS라면 클라이언트 인증(옵션) 을 수행
- 검증 시점:
  * Envoy A: Peer(B)가 제시한 서버 인증서 체인을 로컬 Trust Bundle의 루트까지 검증 + SAN/SPIFFE ID 일치 확인
  * Envoy B: Peer(A)가 제시한 클라이언트 인증서 체인을 검증 + SAN/SPIFFE ID 일치 확인(필요 시 AuthorizationPolicy와 연계)
- 8 이후: 애플리케이션 데이터는 대칭키로 암호화(mTLS 채널). 파드 내부 App↔자기 Envoy 사이는 평문(localhost)
- 세션 재사용: 같은 피어/파라미터에 대해 기존 TLS 세션 재사용(TLS 1.3은 세션 재개/0-RTT 가능, 설정에 따름)
- 실패 처리:
  * 서버 cert 검증 실패 → Envoy A에서 연결 거부
  * 클라이언트 cert 검증 실패(mTLS) → Envoy B에서 연결 거부
  * 정책 불일치(AuthorizationPolicy 등) → Envoy B가 요청 차단

출처

1. Istio 공식 문서 - Security
2. How Are Certificates Managed in Istio?
3. Managing Certificates in Istio with cert-manager and SPIRE

'Istio 공부' 카테고리의 다른 글

Observability의 개념과 필요성 (0)	2025.10.05
Istio에서의 Observability (0)	2025.09.28
서비스 메시(Service Mesh)란 무엇일까? (0)	2025.09.15

istiod가 인증서(Cert) 발급·배포·갱신하는 방법

1. 각 요소의 역할

2. 발급(issuance): 누가 키를 만들고, 누가 서명?

3. 배포(distribution): Envoy가 인증서를 받는 방법

흐름 정리

4. 갱신(rotation): 자동으로 언제, 어떻게 갱신?

5. 요약 diagram

6. 설계 운영상의 이점

⭐️ 결론

(선택) 기업 PKI·체인 연동

1. 기업 PKI?

2. 왜 기업 PKI 체인을 쓰나?

3. 두 가지 운영 패턴

4. Root CA를 두는 이유

5. Intermeiate CA

6. 발급·검증이 실제로 도는 방식(연동 시)

7. mTLS 플로우

출처

'Istio 공부' 카테고리의 다른 글

티스토리툴바