AuthorizationPolicy 멘탈모델 — inbound 적용·mTLS identity·HTTP vs TCP·egress (출처: ChatGPT "Istio 운영 노하우" 대화 + Istio 1.30 공식 문서)

• 대상환경: Istio 1.30, sidecar mesh, security.istio.io/v1
• 대상독자: "AuthorizationPolicy가 안 먹는다 / TCP가 통째로 끊겼다"를 겪는 DevOps/SRE
• 범위: 평가 멘탈모델 — selector 의미, 평가 순서, mTLS 의존 조건, egress/passthrough, HTTP vs TCP 함정
• 선행개념: sidecar inbound/outbound listener, mTLS, SPIFFE identity(SAN), xDS LDS

01. 배경 — authz는 어떤 문제를 푸는가, 왜 mTLS가 전제인가

먼저 "왜 이 리소스가 존재하나"부터. mesh 안에서 서비스 A가 서비스 B를 호출할 때, B는 한 가지 질문에 답해야 한다: "지금 나에게 들어온 이 요청을 처리해도 되나?" network reachability(누가 나에게 패킷을 보낼 수 있나)는 L3/L4 방화벽의 영역이고, AuthorizationPolicy는 그보다 한 층 위 — application 수준의 인가(authorization) — 를 담당한다. "POST /admin은 admin SA만", "payments namespace에서 온 GET만" 같은 규칙이다.

그러면 B는 "누가 호출했는가"를 무엇으로 믿을까? 여기서 mTLS가 전제로 들어온다. 평문 네트워크에서 server가 client를 식별할 수단은 전부 약하다.

IP?        믿기 어려움. NAT, proxy, pod 재생성, spoofing 문제.
Header?    app이 위조 가능.
JWT?       end-user identity에는 좋지만 service-to-service identity와는 별도.
mTLS cert? sidecar가 workload identity로 발급받고 handshake에서 검증.

그래서 Istio의 service-to-service 인가는 mTLS로 증명된 workload identity 위에 선다. authz가 보는 "누가"의 정본 출처는 peer certificate의 SPIFFE SAN이다. 이 의존 관계 — mTLS가 없으면 principal 조건을 쓸 수 없다 — 가 이 문서 전체의 골격이고, §03·§04에서 메커니즘으로 풀어낸다. SPIFFE 형식·SDS provisioning의 디테일은 mTLS/SPIFFE 신원이 정본이다.

이 문서는 사용자가 "AuthorizationPolicy를 잘 모르겠다"고 한 지점에서 출발한다. 그래서 정의 → 평가 → identity 토대 → 조건 경계 → egress → TCP 함정 순으로, 운영에서 실제로 터지는 사고까지 한 줄로 잇는다.

02. anchor — authz는 "보호받는 서버"의 inbound를 본다

가장 많이 헷갈리는 지점부터 못 박는다. 머리에 하나만 담는다면 이것이다.

평가가 일어나는 지점을 그림으로 박으면 나머지가 따라온다 — 검사는 server측 sidecar의 inbound에서 일어난다.

예시 정책으로 이 anchor를 확인한다.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-productpage
  namespace: default
spec:
  selector:
    matchLabels:
      app: reviews          # 이 정책의 보호 대상 = reviews
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/productpage
    to:
    - operation:
        methods: ["GET"]
        paths: ["/reviews/*"]

이 정책의 의미는 "reviews workload로 들어오는 요청 중 source principal이 productpage SA이고 GET /reviews/*인 것만 허용"이다.

• productpage의 outbound를 막는 정책이 아님.
• reviews의 inbound를 보호하는 정책임.

이 한 줄을 잡으면 "왜 내 정책이 안 먹지?"의 절반이 해결된다. 대부분 정책을 잘못된 쪽(client) workload에 selector로 붙였기 때문이다. selector가 client를 가리키면 그 client의 inbound만 제어할 뿐 outbound는 손대지 못한다 — 이 함정은 §06에서 따로 다룬다.

03. 메커니즘 (1) — 부착 대상 결정과 평가 순서

anchor("inbound에 RBAC filter를 심는다")를 두 갈래로 푼다: 어느 Envoy에 심나(부착), 심긴 rule이 어떻게 판정하나(평가).

부착 대상 — namespace + selector (+ targetRefs)

정책이 어떤 Envoy에 부착되는지는 다음으로 결정된다.

metadata.namespace      → 그 namespace의 workload에 적용
+ selector.matchLabels  → 해당 label workload로 좁힘
(+ targetRefs)          → gateway 등 특정 리소스 지정

• namespace에만 두고 selector를 비우면 그 namespace 전체 workload에 적용됨.
• selector를 넣으면 매칭되는 label의 workload로 범위를 좁힘.
• root namespace(istio-system)에 selector 없이 두면 mesh 전역 정책이 됨.

표현을 정확히 하면 "sidecar에 정책을 적용한다"가 아니라, selector → istiod → Envoy inbound listener의 RBAC filter라는 변환이다.

AuthorizationPolicy selector가 특정 workload를 선택한다
→ istiod가 그 workload의 Envoy inbound listener에 RBAC filter를 삽입한다
→ 그 workload로 들어오는 traffic을 검사한다

이 변환은 xDS의 LDS로 내려간다. 검증하려면 istioctl proxy-config listener <pod> -o json에서 RBAC filter를 봐야 함 (→ xDS 계층과 진단). 즉 AuthorizationPolicy는 추상 정책이 아니라 Envoy filter chain에 박히는 구체물이고, "안 먹는다"는 거의 항상 이 filter가 엉뚱한 listener에 박혔거나 아예 안 박힌 상태다.

평가 순서 — CUSTOM → DENY → ALLOW

한 inbound 요청이 RBAC filter를 통과할 때의 판정 규칙이다.

4번과 5번의 비대칭이 운영에서 중요하다. ALLOW 정책을 처음 하나 추가하는 순간, 그 workload는 "기본 허용"에서 "명시 허용 외 전부 차단"으로 바뀐다. 좁은 ALLOW 하나를 잘못 걸면 멀쩡하던 트래픽이 한꺼번에 막힌다 — 이 "첫 ALLOW의 비대칭"은 STRICT 전환과 겹칠 때 가장 위험하다(§정리/What you might be missing).

요청 1건이 어떻게 판정되는지 흐름으로 보면 이렇다.

04. 메커니즘 (2) — mTLS가 identity를 만들고, 그게 정책 입력이 된다

principals 정책을 이해하려면 mTLS의 본질을 잡아야 한다. 핵심은 "암호화"가 아니라 "증명"이다.

일반 TLS는 단방향 인증이다. client만 server를 검증한다.

Client → Server
Client: 너 진짜 server 맞아?
Server: 응, 내 인증서 봐.
Client: OK. 암호화 통신하자.

mTLS는 양방향이다. 서버도 client cert를 요구하고, 양측이 한 handshake 안에서 서로의 identity를 검증한다. 이 handshake 한 번에서 server측 Envoy가 "peer가 누구인가"를 확정하기 때문에, 이후 RBAC filter가 그 값을 그대로 쓸 수 있다.

이렇게 교환된 상대 cert의 SPIFFE identity가 authz의 principals 입력이 된다. 서버 입장에서 "client가 누구인가"의 답은 peer cert의 SPIFFE SAN이고, Istio는 이를 Kubernetes ServiceAccount에 1:1로 매핑한다.

cluster.local/ns/default/sa/productpage
cluster.local/ns/payments/sa/payment-api
cluster.local/ns/inference/sa/model-gateway

이 SAN이 곧 source.principal 조건과 비교되는 값이다.

게다가 client side Envoy는 secure naming check까지 수행한다. 즉 "연결 대상 service의 server cert SAN(SPIFFE identity)이, 그 service에 기대되는 service account와 일치하는가"를 검증한다 — DNS/IP가 엉뚱한 workload로 hijack돼도 cert SAN이 기대값과 다르면 거부된다. 이로써 identity 증명은 server측(누가 들어왔나)뿐 아니라 client측(내가 옳은 server에 붙었나)에서도 양방향으로 닫힌다.

한 줄 요약 — 이것이 principals:로 시작하는 모든 정책의 토대다.

mTLS = 암호화 + 상대 workload identity 증명
AuthorizationPolicy = 그 identity를 보고 허용/차단

05. 메커니즘 (3) — "Envoy가 본 것"이 조건의 경계를 긋는다

§04에서 따라 나오는 핵심 원리: Envoy는 자신이 실제로 본 것만으로 판단한다. mTLS handshake가 없으면 peer cert가 없으니 identity를 모르고, TLS를 terminate 안 하면 HTTP를 못 보니 method/path를 모른다. 그래서 authz 조건은 "peer certificate가 있어야만 쓸 수 있는 것"과 "L4/TLS 정보만으로 되는 것"으로 갈린다. 이 경계를 모르면 mTLS 없는 구간에 principal 정책을 걸어놓고 "왜 안 먹지"로 헤맨다.

표는 결국 "Envoy가 그 정보를 볼 수 있는 layer"로 정렬돼 있다 — L4(언제나 보임) → TLS metadata(ClientHello만 보면 됨) → L7(복호화해야 보임) → identity(peer cert가 있어야 보임).

검증법: peer cert 유무·HTTP 가시성은 istioctl proxy-config listener <pod> -o json의 inbound filter chain에서 확인한다(mTLS면 transport_socket에 TLS context, RBAC filter에 principal 조건이 보임). 실제 거부 원인은 Envoy access log의 RBAC 거부(RBAC: access denied)와 대조해 어느 rule이 걸렸는지 좁힌다.

06. anchor 적용 — client에 걸어도 outbound는 안 막힌다

이제 anchor를 실전 함정에 적용한다. 첫 번째: "이 서비스가 외부로 못 나가게" 하려고 client workload에 정책을 걸면? 답은 outbound는 안 막힌다.

metadata:
  namespace: app
spec:
  selector:
    matchLabels:
      app: client          # client라는 workload를 selector로 골라도...

이 정책은 "client app으로 들어오는 inbound traffic"을 제어한다. client app이 api.vendor.com으로 나가는 outbound를 직접 막지 못한다. selector가 고른 workload의 inbound만 검사하기 때문이다(§02 anchor 그대로).

client의 egress를 통제하려면 별도 메커니즘 조합이 필요하다 — 그리고 그 조합 안에서 authz는 다른 위치(egress gateway의 inbound)로 다시 등장한다(§07).

1. outboundTrafficPolicy: REGISTRY_ONLY     # 미등록 외부 차단
2. ServiceEntry로 허용 목적지만 등록
3. Sidecar egress.hosts로 config scope 제한
4. egress gateway로 외부 통신 강제
5. egress gateway workload에 AuthorizationPolicy 적용  ← 여기서 authz가 다시 등장
6. Kubernetes NetworkPolicy / CNI egress policy
7. 별도 firewall / NAT gateway policy

주의: Sidecar egress.hosts는 프록시 설정량을 줄이는 scope 장치이지 보안 차단 장치가 아니다. scope 밖 목적지가 반드시 차단되는 건 아니라는 점을 구분해야 함.

07. anchor 적용 — egress gateway도 "하나의 workload"다

5번 항목이 핵심이다. egress gateway는 "mesh 밖으로 나가는 출구"지만, Envoy 관점에서는 그냥 하나의 workload다. anchor를 그대로 적용하면: egress traffic을 authz로 통제하려면 egress gateway workload에 inbound 정책으로 건다. (client의 outbound가 아니라 gateway의 inbound가 평가 지점이다.)

client pod
  outbound sidecar
      ↓
egress gateway service
      ↓
egress gateway pod inbound listener  ← AuthorizationPolicy 적용 가능
      ↓
egress gateway outbound
      ↓
external service

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-specific-client-to-egress-gateway
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: egressgateway      # gateway도 하나의 workload
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/app/sa/client
    to:
    - operation:
        ports: ["443"]

의미: "egressgateway로 들어오는 요청 중 source principal이 app/client SA인 것만 허용". 이것이 가능하려면 — §04의 원리상 — sidecar↔egress gateway 구간에 mTLS가 있어야 principal을 알 수 있다. 그 mTLS가 없는 흔한 구성이 다음 절의 passthrough다.

egress TLS passthrough — 두 개의 TLS를 분리해서 보라

운영에서 가장 자주 혼동되는 구성이다. 상황을 이렇게 가정한다.

app → HTTPS 요청 생성 → sidecar → egress gateway → external HTTPS server

egress gateway는 TLS PASSTHROUGH
sidecar ↔ egress gateway 사이에는 Istio mTLS를 쓰지 않음

여기엔 서로 다른 두 개의 TLS가 있고, 이를 섞으면 헷갈린다.

[Istio mTLS]      client sidecar ↔ egress gateway     ← source identity의 출처
[External HTTPS]  app or gateway ↔ api.vendor.com      ← 외부 서버 인증

PASSTHROUGH면 gateway는 application HTTPS를 복호화하지 않고 SNI로만 route해 as-is로 forward한다. "Envoy가 본 것"(§05) 원리대로 가시성이 제한된다.

볼 수 있음:  TCP source/destination, port, TLS ClientHello의 SNI
볼 수 없음:  HTTP method, HTTP path, HTTP header, request body

따라서 mTLS 없는 passthrough 구간에서는 port / source.ip / connection.sni 기반 정책만 가능하다.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-sni-to-vendor
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: egressgateway
  action: ALLOW
  rules:
  - to:
    - operation:
        ports: ["443"]
    when:
    - key: connection.sni
      values:
      - api.vendor.com

하지만 이 정책은 "어느 service account가 호출했는지"를 검증하지 못한다. mTLS가 없어 peer cert가 없기 때문이다(§04 토대 부재).

source identity를 원하면 — sidecar↔gateway 구간 ISTIO_MUTUAL

sidecar↔egress gateway 구간을 Istio mTLS로 만들면 gateway가 source workload identity(cluster.local/ns/app/sa/client)를 알 수 있다. 이를 위해 egress gateway를 대상으로 하는 DestinationRule에 ISTIO_MUTUAL을 건다.

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: egressgateway-for-vendor
  namespace: app
spec:
  host: istio-egressgateway.istio-system.svc.cluster.local
  trafficPolicy:
    portLevelSettings:
    - port:
        number: 443
      tls:
        mode: ISTIO_MUTUAL
        sni: api.vendor.com

그러면 gateway에서 principal 기반 정책이 의미를 갖는다.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-client-to-egress-vendor
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: egressgateway
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/app/sa/client
    to:
    - operation:
        ports: ["443"]
    when:
    - key: connection.sni
      values:
      - api.vendor.com

정리하면 두 축(mTLS 유무 × TLS terminate 유무)이 독립적으로 조건 집합을 깎는다.

sidecar↔egress gateway에 mTLS 없음
  → principal 불가, port/source.ip/connection.sni 만 가능
PASSTHROUGH
  → HTTP method/path/header 불가 (복호화 안 함)
source identity 원함
  → sidecar↔gateway 구간 ISTIO_MUTUAL 필요

관련 실측은 Egress mTLS 리포트 — HTTPS over mTLS (ISTIO_MUTUAL)로 확인.

08. 사고 사례 — HTTP vs TCP DENY 비대칭

이건 실제 운영에서 꽤 자주 터지는 사고 유형이고, §05의 "Envoy가 본 것" 원리가 가장 날카롭게 드러나는 지점이다.

원리: AuthorizationPolicy는 적용 workload의 inbound에 걸린다. operation에 ports를 안 쓰면 모든 port에 열린 것처럼 동작한다. 그런데 TCP에는 HTTP method가 없다. PostgreSQL(5432), Redis(6379), Kafka(9092)는 method라는 개념 자체가 없다.

사고 재현

workload가 HTTP/TCP 혼재라고 하자.

app=my-service
ports:
  8080 HTTP
  9432 TCP

이 위험한 DENY 정책:

spec:
  selector:
    matchLabels:
      app: my-service
  action: DENY
  rules:
  - to:
    - operation:
        methods: ["POST"]        # ports 없음!

결과:

HTTP 8080 POST → DENY  (method 매칭)
HTTP 8080 GET  → 안 걸림 (method 불일치 → POST 아님)
TCP 9432       → DENY됨! HTTP 필드(methods)가 TCP에서 skip되어
                 조건 없는 DENY로 붕괴 → connection 거부

HTTP인 GET은 안 걸리는데 method 개념조차 없는 TCP(9432)는 막히는 비대칭이 사고의 본질이다. DB로 가던 9432 TCP가 통째로 끊긴다.

안전 패턴 — DENY엔 항상 ports를 좁힌다

spec:
  selector:
    matchLabels:
      app: my-service
  action: DENY
  rules:
  - to:
    - operation:
        ports: ["8080"]          # HTTP port로 scope 한정
        methods: ["POST"]

결과:

HTTP 8080 POST → DENY
HTTP 8080 GET  → 안 걸림
TCP 9432       → 안 걸림 (port 불일치로 rule 자체가 매칭 안 됨)

실전 원칙:

DENY + HTTP attribute(methods/paths/hosts) = 반드시 HTTP port로 scope를 좁힌다.
TCP workload와 HTTP workload가 같은 Pod에 섞이면 AuthorizationPolicy를 더 조심해서 나눈다.
가능하면 selector를 app 단위보다 더 좁힌다.

핵심 정리

멘탈모델 한 줄: selector가 고른 server의 inbound listener에 RBAC filter가 박히고, 그 Envoy가 실제로 본 것(peer cert·복호화된 L7)만으로 판정한다. 평가 순서·mTLS 의존·passthrough 한계·TCP 붕괴가 전부 이 한 문장의 따름정리다.

• target = 보호받는 서버: selector가 고른 workload의 inbound를 검사. client outbound ACL이 아님. "안 먹는다"의 절반은 client에 잘못 붙인 것 — istioctl proxy-config listener로 RBAC filter가 어느 listener에 박혔나 확인.
• 평가 순서 CUSTOM → DENY → ALLOW: ALLOW 0개면 기본 허용, 1개라도 있으면 match만 허용(나머지 거부). AUDIT은 verdict에 무영향 병렬 로그.
• mTLS = 암호화 + identity(SPIFFE cluster.local/ns/X/sa/Y) 증명: principal/namespace/serviceAccounts의 토대. peer cert가 없으면 이 조건군 전부 불가, source.ip/port/connection.sni/HTTP attr만 가능.
• 조건 경계 = Envoy가 본 layer: L4(항상) < TLS metadata(ClientHello) < L7(terminate 필요) < identity(peer cert 필요).
• egress 통제는 gateway의 inbound에 authz: selector: istio: egressgateway. identity 원하면 sidecar↔gateway 구간 ISTIO_MUTUAL. PASSTHROUGH면 HTTP method/path/header 불가.
• TCP 함정: DENY + HTTP attr + no ports = HTTP 필드가 TCP에서 skip → 조건 없는 DENY로 붕괴 → TCP까지 끊김. DENY엔 항상 selector + ports를 좁혀라.

용도별 결론:

server workload 보호        → server workload selector에 authz
egress gateway 사용 권한 제어 → egress gateway selector에 authz
client의 모든 outbound ACL    → authz만으로 부적합.
                              ServiceEntry/Sidecar/outboundTrafficPolicy/
                              egress gateway/NetworkPolicy 조합

What you might be missing

• ALLOW 한 개의 비대칭 효과: ALLOW 정책이 0개일 땐 기본 허용이지만, 첫 ALLOW를 거는 순간 그 workload는 "명시 허용 외 전부 차단"으로 전환된다. STRICT 전환과 함께 ALLOW를 처음 도입할 때 trace 트래픽(health/readiness, telemetry scrape 경로)까지 ALLOW에 포함했는지 확인 필요.
• authz는 identity를 검증하지만 mTLS 강제는 PeerAuthentication의 몫: AuthorizationPolicy에 principals를 써도, PeerAuthentication이 PERMISSIVE면 평문 요청은 peer cert 없이 들어와 principal 조건에서 그냥 deny될 뿐 "평문 거부"가 명시적으로 되는 게 아니다. 평문 자체를 막으려면 PeerAuthentication STRICT가 별도로 필요함. 이 셋(PeerAuthentication=mTLS 강제, RequestAuthentication=JWT 검증, AuthorizationPolicy=허용/차단)의 역할 분담은 세 리소스 역할 분담을 정본으로 참조한다.
• passthrough egress는 SNI 위조에 취약: connection.sni 기반 정책은 ClientHello의 SNI만 믿는다. 악의적 client가 SNI를 위조하면 우회 가능. 강한 보장이 필요하면 sidecar↔gateway ISTIO_MUTUAL로 source identity를 먼저 고정하고 SNI는 보조 조건으로만 써야 함.
• HTTP 필드 skip이 ALLOW↔DENY에서 정반대로 작동: HTTP 전용 필드(methods/paths/headers)는 TCP에서 skip되는데, DENY에서는 "조건이 사라진 무조건 DENY"가 되고 ALLOW에서는 "조건이 매칭 불가 → 매칭 안 됨"이 된다. 그래서 같은 조건이라도 action을 ALLOW↔DENY로 뒤집으면 TCP에 대한 영향이 정반대가 된다 — DENY 정책을 ALLOW로 리팩터링할 때 이 비대칭을 놓치면 의도와 다른 게이트가 생긴다.

참조

• mTLS/SPIFFE 신원 — SPIFFE 형식·SDS provisioning·일반 TLS와의 차이(정본)
• 세 리소스 역할 분담 — PeerAuthentication / RequestAuthentication / AuthorizationPolicy
• xDS 계층과 진단 — RBAC filter가 LDS로 내려가는 것 검증
• Egress mTLS 리포트 — HTTPS over mTLS (ISTIO_MUTUAL) — egress mTLS 실측