7장: mTLS와 제로 트러스트 네트워킹

서비스 메시를 도입하는 가장 일반적인 이유 중 하나가 서비스 간 통신의 보안입니다. 특히 **mTLS(mutual TLS)**는 모든 서비스 메시의 공통 기반 기능이며, 제로 트러스트 네트워킹의 핵심 구성요소입니다. 이 장에서는 mTLS의 작동 원리부터 SPIFFE 아이덴티티 표준, 그리고 실전 보안 전략까지 다루겠습니다.

TLS vs mTLS

일반 TLS

웹 브라우저가 HTTPS로 서버에 접속할 때 사용하는 일반 TLS는 서버만 인증합니다. 클라이언트(브라우저)는 서버의 인증서를 검증하지만, 서버는 클라이언트가 누구인지 알지 못합니다.

일반 TLS 핸드셰이크:
Client → Server: ClientHello
Client ← Server: ServerHello + 서버 인증서
Client:          서버 인증서 검증 (신뢰 여부 확인)
Client → Server: 암호화된 데이터

mutual TLS (mTLS)

mTLS는 양쪽 모두 인증합니다. 서버가 클라이언트의 인증서도 요구하고 검증합니다.

mTLS 핸드셰이크:
Client → Server: ClientHello
Client ← Server: ServerHello + 서버 인증서 + 클라이언트 인증서 요청
Client:          서버 인증서 검증
Client → Server: 클라이언트 인증서
Server:          클라이언트 인증서 검증
양방향 암호화 채널 수립

마이크로서비스 환경에서 mTLS는 세 가지를 보장합니다.

1. 기밀성(Confidentiality): 통신 내용이 암호화되어 도청이 불가능합니다
2. 인증(Authentication): 양쪽 서비스의 신원이 인증서로 확인됩니다
3. 무결성(Integrity): 전송 중 데이터 변조가 감지됩니다

서비스 메시에서의 투명한 mTLS

서비스 메시의 mTLS가 특별한 이유는 투명성입니다. 애플리케이션 코드를 전혀 수정하지 않고도 모든 서비스 간 통신에 mTLS가 적용됩니다.

애플리케이션 관점:
[서비스 A] → HTTP (평문) → [서비스 B]

실제 네트워크:
[서비스 A] → [프록시 A] → mTLS (암호화) → [프록시 B] → [서비스 B]

프록시가 아웃바운드 트래픽을 가로채어 TLS를 시작하고, 인바운드 측 프록시가 TLS를 종료합니다. 애플리케이션은 평문 HTTP로 통신한다고 인식하지만, 실제 네트워크에서는 암호화된 트래픽이 흐릅니다.

SPIFFE: 워크로드 아이덴티티 표준

SPIFFE란

**SPIFFE(Secure Production Identity Framework for Everyone)**는 분산 시스템에서 워크로드의 아이덴티티를 표현하는 표준입니다. CNCF 졸업 프로젝트로, 서비스 메시의 아이덴티티 계층에서 사실상의 표준으로 자리 잡았습니다.

SPIFFE ID

SPIFFE ID는 워크로드의 고유 식별자로, URI 형식을 따릅니다.

spiffe://trust-domain/path

예시:
spiffe://cluster.local/ns/production/sa/reviews
         ^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^
         신뢰 도메인     워크로드 경로 (네임스페이스/서비스어카운트)

Istio에서는 Kubernetes의 네임스페이스와 ServiceAccount를 기반으로 SPIFFE ID를 자동 생성합니다.

SVID (SPIFFE Verifiable Identity Document)

SVID는 SPIFFE ID를 포함하는 암호학적 문서입니다. X.509 인증서 형태로 발급되며, mTLS 핸드셰이크에서 워크로드의 신원을 증명합니다.

X.509-SVID 구조:
┌─────────────────────────────────────┐
│ Subject Alternative Name (SAN):      │
│   URI: spiffe://cluster.local/ns/   │
│         production/sa/reviews        │
│                                      │
│ Issuer: Istiod CA                    │
│ Valid: 2026-04-28T00:00:00Z          │
│   ~ 2026-04-29T00:00:00Z (24시간)   │
│ Public Key: ...                      │
└─────────────────────────────────────┘

인증서 관리

서비스 메시의 mTLS를 운영하려면 수천 개의 인증서를 자동으로 발급, 갱신, 배포해야 합니다.

Istio의 인증서 계층

Root CA (Trust Anchor)
│ 유효 기간: 10년 (기본)
│
└── Intermediate CA (Istiod)
    │ 유효 기간: 3년 (기본)
    │
    ├── Workload Cert (Pod A)
    │   유효 기간: 24시간, 12시간마다 갱신
    │
    ├── Workload Cert (Pod B)
    │   유효 기간: 24시간, 12시간마다 갱신
    │
    └── ...

인증서 발급 흐름:

외부 CA 연동

프로덕션 환경에서는 Istiod 자체 CA 대신 조직의 PKI와 연동하는 것이 일반적입니다.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: istio-ca
  namespace: istio-system
spec:
  ca:
    secretName: istio-ca-secret

Vault, AWS Private CA, Google Cloud CAS 등 외부 CA를 Istiod에 연결하여 인증서 발급을 위임할 수 있습니다.

제로 트러스트 네트워킹

제로 트러스트의 원칙

제로 트러스트는 "네트워크 위치에 기반한 암묵적 신뢰를 제거한다"는 원칙입니다.

전통적 모델 (경계 기반 보안):

[인터넷] → [방화벽] → [내부 네트워크: 모두 신뢰]
                        Pod A ←→ Pod B (평문, 인증 없음)

제로 트러스트 모델:

[인터넷] → [방화벽] → [내부 네트워크: 아무도 신뢰하지 않음]
                        Pod A ←(mTLS + 인가 정책)→ Pod B
                        같은 노드여도 인증 필요

서비스 메시로 구현하는 제로 트러스트

서비스 메시는 제로 트러스트의 네 가지 핵심 요소를 제공합니다.

1. 워크로드 아이덴티티: SPIFFE 기반의 암호학적 아이덴티티로 서비스를 식별합니다. IP 주소가 아닌 아이덴티티가 신뢰의 기준입니다.

2. 전구간 암호화: mTLS로 모든 서비스 간 통신을 암호화합니다. 같은 노드 내 Pod 간 통신도 예외가 아닙니다.

3. 명시적 인가: 기본적으로 모든 접근을 거부하고, 명시적으로 허용된 통신만 허가합니다.

# 1. 네임스페이스 기본 정책: 모든 접근 거부
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  {}  # 빈 규칙 = 모든 접근 거부
---
# 2. 특정 서비스 간 통신만 허용
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  selector:
    matchLabels:
      app: backend
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/production/sa/frontend"
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/*"]

4. 지속적 검증: 인증서의 짧은 유효 기간과 자동 갱신으로 자격 증명이 지속적으로 검증됩니다.

점진적 제로 트러스트 도입

한 번에 모든 서비스에 엄격한 정책을 적용하면 서비스 장애가 발생할 수 있습니다. 점진적 접근을 권장합니다.

단계별 도입:

1단계: 관찰 (Permissive mTLS)
  - mTLS를 PERMISSIVE 모드로 설정
  - 평문과 mTLS 트래픽 모두 허용
  - 트래픽 패턴 파악

2단계: 암호화 강제 (Strict mTLS)
  - mTLS를 STRICT 모드로 전환
  - 모든 통신이 암호화됨
  - 인가 정책은 아직 미적용

3단계: 감사 모드 (Audit)
  - AuthorizationPolicy를 AUDIT 모드로 설정
  - 정책 위반을 로그에만 기록
  - 실제 트래픽은 차단하지 않음

4단계: 정책 적용 (Enforce)
  - 감사 로그 분석 후 정책 확정
  - ALLOW/DENY 정책 적용
  - 지속적 모니터링

멀티클러스터 mTLS

여러 Kubernetes 클러스터에 걸쳐 서비스 메시를 운영할 때, mTLS 신뢰 관계를 클러스터 간에 수립해야 합니다.

공유 Trust Anchor

가장 간단한 방법은 모든 클러스터가 동일한 Root CA를 공유하는 것입니다.

공유 Root CA
├── Cluster A의 Intermediate CA
│   └── Cluster A의 워크로드 인증서들
│
└── Cluster B의 Intermediate CA
    └── Cluster B의 워크로드 인증서들

각 클러스터의 Istiod는 고유한 Intermediate CA를 가지지만, 동일한 Root CA로 서명됩니다. 따라서 클러스터 A의 서비스가 클러스터 B의 서비스를 신뢰할 수 있습니다.

SPIRE 연동

대규모 멀티클러스터 환경에서는 **SPIRE(SPIFFE Runtime Environment)**를 중앙 아이덴티티 제공자로 사용하는 것이 권장됩니다.

SPIRE 서버 (중앙)
├── SPIRE 에이전트 (Cluster A 각 노드)
│   └── 워크로드 SVID 발급
│
└── SPIRE 에이전트 (Cluster B 각 노드)
    └── 워크로드 SVID 발급

SPIRE는 Istio, Cilium 모두와 연동할 수 있으며, 통합된 아이덴티티 관리를 제공합니다.

실전 보안 체크리스트

서비스 메시 보안을 올바르게 운영하기 위한 체크리스트입니다.

mTLS 설정:

• STRICT 모드가 활성화되어 있는지 확인
• 인증서 갱신이 정상적으로 동작하는지 모니터링
• Root CA의 만료일을 사전에 추적하고 갱신 계획 수립

인가 정책:

• 기본 거부(deny-all) 정책이 각 네임스페이스에 적용되어 있는지 확인
• 최소 권한 원칙에 따라 필요한 통신만 허용
• 정기적으로 불필요한 허용 규칙 정리

관측:

• mTLS 핸드셰이크 실패 메트릭 모니터링
• 인가 정책 거부 로그 수집 및 분석
• 인증서 만료 임박 알림 설정

핵심 요약

• mTLS는 서비스 간 통신의 기밀성, 인증, 무결성을 동시에 보장합니다
• SPIFFE/SVID가 워크로드 아이덴티티의 사실상 표준이며, 짧은 유효 기간(24시간)으로 보안을 강화합니다
• 서비스 메시는 투명한 mTLS를 제공하여 애플리케이션 코드 변경 없이 암호화를 적용합니다
• 제로 트러스트는 관찰 → 암호화 → 감사 → 정책 적용의 단계로 점진적으로 도입해야 합니다
• 멀티클러스터 환경에서는 공유 Trust Anchor 또는 SPIRE를 통한 통합 아이덴티티 관리가 필요합니다

다음 장에서는 서비스 메시가 제공하는 관측 가능성 기능을 다루겠습니다.