Istio 보안 실전 — mTLS, AuthorizationPolicy, 그리고 제로트러스트 메시

spiffe://cluster.local/ns/payments/sa/payments-api
         -------------    --------    ------------
         트러스트 도메인    네임스페이스   서비스어카운트

+----------------------------------------------------------------------+
|  컨트롤 플레인                                                         |
|  +----------------------------------------------------------------+  |
|  | istiod (내장 CA)                                                |  |
|  |  - 루트/중간 CA 키 보관 (istio-ca-secret 또는 cacerts)            |  |
|  |  - CSR 서명, SPIFFE ID를 SAN에 기록                              |  |
|  +----------------------------------------------------------------+  |
|        ^                                        |                    |
|        | 3. CSR 제출                             | 4. 서명된 인증서      |
|        |    (서비스어카운트 토큰으로 인증)            |    (기본 24시간 유효) |
+--------|----------------------------------------|--------------------+
         |                                        v
+--------|----------------------------------------------------------+
|  워크로드 파드                                                       |
|  +--------------------------+    +------------------------------+ |
|  | istio-agent (pilot-agent) |<-->| Envoy 사이드카                | |
|  |  1. 키 쌍 생성             | SDS |  - 발급받은 인증서로           | |
|  |  2. CSR 생성              |    |    mTLS 핸드셰이크            | |
|  |  5. SDS로 Envoy에 전달     |    |  - 상대 인증서의 SPIFFE ID 검증| |
|  |  6. 만료 전 자동 재발급      |    +------------------------------+ |
|  +--------------------------+                                      |
+--------------------------------------------------------------------+

# 1) 메시 전역 기본값 — istio-system(루트 네임스페이스)에 둔다
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
---
# 2) 네임스페이스 단위 — 해당 네임스페이스의 모든 워크로드에 적용
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: payments
spec:
  mtls:
    mode: STRICT
---
# 3) 워크로드 단위 — selector로 특정 워크로드만, 포트별 예외도 가능
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: legacy-metrics-exception
  namespace: payments
spec:
  selector:
    matchLabels:
      app: legacy-batch
  mtls:
    mode: STRICT
  portLevelMtls:
    9090:                    # 메시 밖 Prometheus가 긁어가는 포트만 평문 허용
      mode: PERMISSIVE

단계 0: 현황 관찰 (PERMISSIVE 유지)
  - Grafana/Kiali에서 평문 트래픽 비율 확인
  - 메트릭: istio_requests_total의
    connection_security_policy 라벨 (mutual_tls / none)
  - none이 잡히는 출발지를 전수 조사
    → 사이드카 미주입 파드인가, 메시 밖 클라이언트인가

단계 1: 평문 출발지 제거
  - 사이드카 미주입 네임스페이스에 주입 라벨 추가
  - 메시 밖 클라이언트는 메시로 편입하거나 ingress gateway 경유로 변경

단계 2: 비핵심 네임스페이스부터 STRICT 적용
  - dev → staging → 운영 비핵심 → 운영 핵심 순서
  - 네임스페이스당 PeerAuthentication 하나로 명시적 적용
  - 적용 후 5xx/연결 오류 대시보드를 일정 기간 관찰

단계 3: 메시 전역 기본값을 STRICT로
  - istio-system의 default PeerAuthentication을 STRICT로
  - 남은 예외는 portLevelMtls 또는 워크로드 단위로 좁게 명시

단계 4: 예외 목록을 주기적으로 재심사
  - DISABLE/PERMISSIVE 예외는 만료일을 정해 관리

# 특정 워크로드의 mTLS 적용 상태와 정책 출처 확인
istioctl x describe pod payments-api-6c9f7d-abcde -n payments

# 네임스페이스의 인증 정책 충돌/누락 점검
istioctl analyze -n payments

# Prometheus에서 평문 요청 추적 (none이 0이 되어야 STRICT 가능)
# istio_requests_total{connection_security_policy="none"}

AuthorizationPolicy 평가 순서 (요청 하나당):

1. CUSTOM 정책 평가 → 외부 인가기가 거부하면 즉시 거부
2. DENY 정책 평가   → 하나라도 매칭되면 즉시 거부
3. ALLOW 정책 평가
   - 대상 워크로드에 ALLOW 정책이 하나도 없으면 → 허용 (기본 개방)
   - ALLOW 정책이 하나라도 있으면 → 매칭되는 것이 있어야 허용,
     없으면 거부 (기본 거부로 전환)

# 빈 spec의 ALLOW 정책 = 아무것도 허용하지 않음 = 네임스페이스 기본 거부
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: payments
spec: {}

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payments-api-allow
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payments-api
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/commerce/sa/orders-api   # SPIFFE ID 기반
      to:
        - operation:
            methods: ["POST"]
            paths: ["/v1/charges", "/v1/refunds"]
    - from:
        - source:
            principals:
              - cluster.local/ns/observability/sa/prometheus
      to:
        - operation:
            methods: ["GET"]
            paths: ["/metrics"]

# 관리용 경로는 어떤 출발지에서도 메시 내부 호출 금지
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-admin-paths
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payments-api
  action: DENY
  rules:
    - to:
        - operation:
            paths: ["/admin/*", "/internal/*"]
---
# 특정 네임스페이스 전체에서 오는 트래픽 차단 (예: 샌드박스 격리)
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-from-sandbox
  namespace: payments
spec:
  action: DENY
  rules:
    - from:
        - source:
            namespaces: ["sandbox"]

# ingress gateway를 거쳐 들어온 외부 트래픽만 허용하고,
# 특정 헤더가 있는 요청만 통과시키는 예
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: frontend-via-gateway-only
  namespace: commerce
spec:
  selector:
    matchLabels:
      app: storefront
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/istio-ingress/sa/ingress-gateway
      when:
        - key: request.headers[x-api-version]
          values: ["v1", "v2"]

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: jwt-auth
  namespace: commerce
spec:
  selector:
    matchLabels:
      app: storefront-api
  jwtRules:
    - issuer: "https://idp.example.com/"          # iss 클레임과 일치해야 함
      audiences:
        - "storefront-api"                         # aud 클레임 검증
      jwksUri: "https://idp.example.com/.well-known/jwks.json"
      forwardOriginalToken: true                   # 백엔드로 토큰 전달

# 유효한 JWT principal이 있는 요청만 허용 → 토큰 없으면 거부
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: commerce
spec:
  selector:
    matchLabels:
      app: storefront-api
  action: ALLOW
  rules:
    - from:
        - source:
            requestPrincipals: ["https://idp.example.com//*"]  # iss/sub 형식
---
# 클레임 기반 세분화: 관리자 스코프가 있어야 쓰기 허용
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: write-requires-admin-scope
  namespace: commerce
spec:
  selector:
    matchLabels:
      app: storefront-api
  action: ALLOW
  rules:
    - to:
        - operation:
            methods: ["GET"]
    - to:
        - operation:
            methods: ["POST", "PUT", "DELETE"]
      when:
        - key: request.auth.claims[scope]
          values: ["storefront:admin"]

# MeshConfig (IstioOperator 또는 istio ConfigMap)
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    extensionProviders:
      - name: opa-ext-authz
        envoyExtAuthzGrpc:
          service: opa.authz-system.svc.cluster.local
          port: 9191
          timeout: 0.5s          # 인가기 지연이 전체 지연에 직결 — 짧게

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: opa-authz
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payments-api
  action: CUSTOM
  provider:
    name: opa-ext-authz
  rules:
    - to:
        - operation:
            paths: ["/v1/charges"]    # 비용이 큰 외부 인가는 필요한 경로만

# Rego 정책 예시 (envoy.authz 패키지)
package envoy.authz

default allow := false

# 주문 서비스가 호출했고, JWT의 tier 클레임이 premium이면 허용
allow if {
    input.attributes.source.principal ==
        "spiffe://cluster.local/ns/commerce/sa/orders-api"
    claims := input.attributes.metadata_context.filter_metadata["envoy.filters.http.jwt_authn"].fields
    claims["tier"] == "premium"
}

# 사내 PKI에서 받은 중간 CA로 cacerts 시크릿 구성
kubectl create secret generic cacerts -n istio-system \
  --from-file=ca-cert.pem \
  --from-file=ca-key.pem \
  --from-file=root-cert.pem \
  --from-file=cert-chain.pem
# istiod 재시작 후 신규 워크로드 인증서는 이 체인으로 발급됨

# cert-manager Issuer 예: Vault PKI 백엔드에 서명 위임
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: vault-istio-ca
spec:
  vault:
    server: https://vault.corp.example:8200
    path: pki_int_mesh/sign/istio-workload
    auth:
      kubernetes:
        role: istio-csr
        mountPath: /v1/auth/kubernetes
        secretRef:
          name: istio-csr-vault-token
          key: token

istio-csr 구성 시 발급 흐름:

워크로드 istio-agent
   → CSR → istiod
            → istio-csr (gRPC CA 서버로 등록됨)
               → cert-manager CertificateRequest
                  → ClusterIssuer (Vault / Private CA / 사내 PKI)
                     → 서명된 인증서가 역순으로 전달

효과:
- 메시 CA 키가 클러스터 밖(HSM/Vault)에 보관됨
- 발급 이력이 cert-manager 리소스로 남아 감사 가능
- 발급자 교체가 Issuer 교체로 단순화

# 워크로드 인증서 체인과 만료 확인
istioctl proxy-config secret deploy/payments-api -n payments -o json

# istiod CA 인증서 만료 모니터링 (Prometheus)
# 메트릭: citadel_server_root_cert_expiry_timestamp
# 만료 30일 전 알림 규칙을 반드시 걸어둘 것

# 1) RBAC 디버그 로그 활성화 (대상 파드)
istioctl proxy-config log deploy/payments-api -n payments \
  --level rbac:debug

# 2) 사이드카 로그에서 거부 사유 확인
kubectl logs deploy/payments-api -n payments -c istio-proxy --tail=100
# "RBAC: access denied" 와 함께 매칭 실패한 principal/경로가 출력됨

# 3) 워크로드에 적용 중인 인가 정책 전체 확인
istioctl x describe pod payments-api-6c9f7d-abcde -n payments

# 4) 정책 정합성 일괄 점검
istioctl analyze -n payments

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all-dryrun
  namespace: payments
  annotations:
    istio.io/dry-run: "true"     # 평가만 하고 실제로 차단하지 않음
spec: {}

권장 정책 배포 절차:

1. dry-run으로 정책 배포
2. 일정 기간 shadow denied 로그/메트릭 수집
   (istio_requests_total 및 액세스 로그의 dry-run 결과 확인)
3. 거부 목록이 의도와 일치하는지 검토
   → 의도하지 않은 거부가 있으면 rules 보완
4. dry-run 어노테이션 제거 (정책 활성화)
5. 활성화 직후 403 비율 대시보드 집중 관찰

+------------------------------------------------------------------+
| 단계 1. 관찰 (1~2주)                                               |
|  - 사이드카 주입 완료, PERMISSIVE 기본값 유지                        |
|  - Kiali/Grafana로 서비스 호출 그래프와 평문 비율 파악                |
|  - 산출물: 서비스 간 호출 매트릭스 (인가 정책의 설계 입력)              |
+------------------------------------------------------------------+
| 단계 2. mTLS STRICT 전환 (네임스페이스 단위, 2~4주)                  |
|  - 평문 출발지 제거 → dev부터 단계 적용 → 전역 STRICT                |
|  - 예외는 portLevelMtls로 좁게, 만료일 관리                         |
+------------------------------------------------------------------+
| 단계 3. 인가 정책 (핵심 서비스부터)                                   |
|  - 호출 매트릭스 기반 ALLOW 정책 작성 → dry-run 검증 → 활성화         |
|  - 네임스페이스 기본 거부는 충분한 dry-run 후에                       |
|  - 관리 경로 DENY, gateway 경유 강제 등 안전망 추가                  |
+------------------------------------------------------------------+
| 단계 4. 고도화                                                     |
|  - RequestAuthentication으로 JWT 검증을 진입 지점에                 |
|  - 데이터 의존 판단은 OPA ext-authz로 좁게                          |
|  - 커스텀 CA/사내 PKI 통합, CA 만료 모니터링 체계화                   |
+------------------------------------------------------------------+