istio vs cilium 정책 차이

 

 

• 레이어/역할
  • Istio: 서비스 메쉬의 L7(HTTP/gRPC) 중심 접근제어 + mTLS/JWT 인증/인가. AuthorizationPolicy(ALLOW/DENY/CUSTOM/AUDIT), PeerAuthentication(mTLS), RequestAuthentication(JWT)로 앱 레벨 보안/정책을 다룸. Sidecar 모드에선 Envoy 사이드카가, Ambient에선 L4 정책은 ztunnel, L7은 waypoint가 집행한다. Istio
  • Cilium: CNI + eBPF 기반 L3/L4(커널 레벨) 정책이 기본. 확장 리소스인 CiliumNetworkPolicy/ClusterwideNetworkPolicy로 L3/L4는 eBPF로, **L7(HTTP/gRPC/Kafka/DNS)**은 노드 로컬 Envoy를 붙여 집행한다. FQDN/DNS 정책, 클러스터 전역 정책도 지원. docs.cilium.io
• 기본 동작과 우선순위
  • Istio: 기본적으로 정책이 없으면 허용(allow-all). ALLOW 정책이 하나라도 적용되면 매치되지 않는 트래픽은 거부(deny-by-default)로 바뀜. 평가 순서는 CUSTOM → DENY → ALLOW. DENY가 ALLOW보다 우선이라, DENY에 걸리면 ALLOW로 못 풀어준다. solo.io
  • Cilium: 기본은 허용(allow-all). **어떤 Cilium 정책이 엔드포인트를 선택하고 ingress/egress 섹션이 있으면 해당 방향은 ‘기본 거부’**로 전환(명시 허용만 통과). ingressDeny/egressDeny(명시적 DENY)는 ALLOW보다 우선한다. docs.cilium.io
• 정책 적용 범위/대상
  • Istio: “메쉬 안의 워크로드”에 대한 ID 기반(L7/L4) 접근제어. 외부로 나가는 트래픽은 기본적으로 통과(ALLOW_ANY)지만, ServiceEntry + (필요시) Egress Gateway로 외부 접근을 허용목록(allowlist) 기반으로 통제 가능. Istio
  • Cilium: Pod/네임스페이스/라벨/엔티티(World, Cluster, Host 등) 기준 L3/L4 제어가 주력. DNS/FQDN 기반 egress 제어로 외부 도메인 단위 통제가 쉽다. docs.cilium.io
• 집행 위치/오버헤드 관점
  • Istio: Sidecar(또는 Ambient waypoint/ztunnel)의 프록시 경유 정책. L7 기능이 풍부하지만 프록시 비용이 있다(특히 L7). Ambient는 L4를 ztunnel에서 처리해 경로 간소화, L7은 waypoint에서. ambientmesh.io
  • Cilium: **L3/L4는 커널(eBPF)**에서 매우 가볍게 집행. L7이 필요할 때만 노드 로컬 Envoy가 개입(정책 적용 Pod의 트래픽만). solo.io

---

정책 모델 비교 (요점 표)

 

항목	Istio	Cilium
주 역할	앱 레벨 인가(L7), mTLS/JWT	네트워크 레벨 격리(L3/L4), 필요 시 L7
리소스	AuthorizationPolicy, Peer/RequestAuthentication	CiliumNetworkPolicy/ClusterwideNetworkPolicy(+ K8s NetworkPolicy)
기본 동작	정책 없으면 허용	정책 없으면 허용
기본 거부 전환	ALLOW 정책 등장 시 매치 외 트래픽 거부	엔드포인트가 정책에 선택되고 ingress/egress 섹션 있으면 그 방향 기본 거부
우선순위	CUSTOM → DENY → ALLOW	ingressDeny/egressDeny가 ALLOW보다 우선
L7 제어	경로/메서드/헤더/JWT 클레임, 외부 인증(CUSTOM)	HTTP/gRPC/Kafka/DNS 규칙(toPorts+HTTP, toFQDNs/DNS Proxy)
외부(egress)	ServiceEntry/Egress GW로 엄격 통제 가능	FQDN/DNS 기반 allowlist가 간단

(각 행의 근거: Istio 정책/평가순서/egress 문서 & Cilium 정책/deny/DNS/FQDN 문서.) docs.cilium.io+5Istio+5Istio+5

---

언제 무엇을 쓰면 좋은가 

1. 기본 방화벽/격리(크로스-네임스페이스 차단, 포트 제한, 외부 도메인 제한)
2. → Cilium으로 L3/L4 기본 거부 + 필요한 것만 허용. 외부는 toFQDNs/DNS로 허용목록 관리. (eBPF라 가볍고, 정책이 간결) docs.cilium.io
3. 사용자/클라이언트 속성 기반의 세밀한 인가 (경로/메서드/헤더/JWT 클레임)
4. → Istio AuthorizationPolicy + RequestAuthentication(JWT). 필요한 경우 외부 인가 시스템으로 CUSTOM 연동(OPAAuthorizer 등). Istio
5. 외부 트래픽을 엄격히 통제(감사/라우팅 포함)
6. → Istio에서 REGISTRY_ONLY + ServiceEntry/Egress Gateway로 도메인/호스트 단위로 제어 및 감사. 또는 Cilium의 FQDN 정책으로 간단 제어(라이트한 요구). Istio

권장 레이어링:

“Cilium(L3/L4 기본 방화벽)” 위에 “Istio(L7 인가 + mTLS/JWT)”를 얹는 2단 구조가 운영에서 가장 예측 가능하고 튼튼한 패턴. Cilium으로 바닥을 좁히고, Istio로 앱 의미의 인가를 입혀라. cilium.io

 

자주 헷갈리는 포인트(함정)

• Istio DENY가 모두를 막는 듯 보일 때
  DENY는 ALLOW보다 우선이므로, DENY 규칙에 포트를 명시하지 않고 HTTP 속성만 적으면 스코프 내 TCP 전부가 차단될 수 있다는 경고가 뜬다. DENY에는 반드시 ports/operation 범위를 정확히 지정하거나, DENY를 최소화하고 ALLOW로 화이트리스트를 만들자. Istio
• Cilium 기본 거부가 갑자기 켜졌을 때
  “정책이 엔드포인트를 선택하고 ingress/egress 섹션이 있으면” 그 방향은 기본 거부로 전환된다. 허용해야 할 트래픽을 빠짐없이 추가하지 않으면 통신이 막힌다. 또한 ingressDeny/egressDeny는 ALLOW보다 우선한다. docs.cilium.io
• L7 성능 고려
  Istio든 Cilium이든 L7 정책을 켜면 Envoy 프록시가 경유된다. Cilium은 L7이 필요한 Pod만 Envoy로 보내고 L3/L4는 커널에서 처리한다. Istio Ambient는 L4는 ztunnel, L7은 waypoint로 분담. 필요한 곳에만 L7을 켜라가 공통 원칙. docs.cilium.io

Istio에서 가능한 L7 정책 기능 vs Cilium의 제한

 

기능	Istio에서 가능	Cilium에서 가능/제한	있음제한 또는 불가능한 이유
JWT 인증 + 클레임 기반 조건 인가 (예: when 키로 JWT 속성 검사)	✅ 가능 — RequestAuthentication + AuthorizationPolicy의 when 필드 사용. HTTP method, path, request.auth.claims 같은 키 지원됨. Istio+2Istio+2	❌ 대부분 불가능 또는 매우 제한적임	Cilium L7 정책은 HTTP path, method 등의 일부를 Envoy 프로몬트(proxy) 기반으로만 지원. 그러나 JWT 토큰 클레임을 검사해서 그에 기반해 정책 분기(branch)하는 Istio 수준만큼의 통합성은 없음. 文서에서 JWT 기반 인가/클레임 기반 허용 조건은 언급이 적음.
조건부 헤더 기반 인가 / 요청 헤더의 복합 조건 (예: 특정 헤더가 있고 동시에 path가 이렇고 method가 그럴 때)	✅ 가능 — Istio의 AuthorizationPolicy에서 operation, from, when: request.headers[...] 조합 가능. Istio+2Istio+2	⚠️ 제한적	Cilium의 L7 정책(toPorts + HTTP/rules 등)에서 HTTP 헤더 조건은 일부 가능하지만 문서상 복합적인 조건 조합, JWT claim + header + path 같이 복잡한 multi-condition 인가는 아직 완전하진 않음. 예: CiliumEnvoyConfig과 같은 CRD를 써야 하는데 검증/충돌 해결(conflict resolution)이 미흡하다는 언급이 있음. docs.cilium.io
정교한 인증체계 (mTLS identity + service account / principal 기반 인가)	✅ 가능 — Istio는 서비스 계정, 서비스 프린서플, TLS 인증서를 통한 원본 신원(source principal) 검사 가능. docs.cilium.io+3Istio+3Istio+3	⚠️ 일부 가능, 일부 제한	Cilium도 identity 기반 필터링은 가능 (pod identity, label, 네임스페이스) but mTLS로 암호화 된 트래픽 내부의 HTTP 레이어까지 들어가서 identity를 기반으로 HTTP-헤더나 JWT 검증까지 하는 것은 Istio 쪽이 더 강함. 특히 Istio가 자체적으로 제공하는 request.auth 클레임 조건 등은 Cilium 쪽에는 공식 문서 상에서 덜 강조됨.
조건부 인가 + 감사(audit) 로그(policy matched but only 기록하고 거부는 안 함)	✅ 가능 — Istio의 AuthorizationPolicy 에서 AUDIT 액션이 있어, 조건 매치시 요청을 허용하면서 감사를 남길 수 있음. Istio	❌ 불가능 또는 문서상 없음	Cilium 문서에서 “허용은 하되 조건이 맞는 경우 감사만 한다”는 정책(거부하지 않고 로그만 남기는) 기능은 명확히 확인된 바 없음. 보통 인가/거부 중심.
확장 가능한 외부 인증(Custom Authorizer / 외부 서비스 연계) (예: Istio의 CUSTOM 액션)	✅ 가능 — Istio AuthorizationPolicy 액션에 CUSTOM type이 있어서 외부 인증자(authorizer)를 연결하거나 확장 가능. Istio	❌ 제한적 또는 없음	Cilium의 문서에서 CUSTOM 같은 외부 authorizer 연결 기능은 언급이 거의 없음. CiliumEnvoyConfig 같은 특정 Envoy 설정을 통해 커스텀 필터 넣는 건 가능하겠지만, Istio처럼 정책 리소스로 쉽게 외부 인증자와 통합하는 건 덜 성숙함.
Https/TLS 종료시 TLS 속성 기반 조건 (예: SNI, TLS 버전, 인증서 주체 등)	✅ 가능 — Istio를 이용해 TLS 설정, mTLS, principal 조건 등이 가능하고, TLS 종료 지점(proxy가 TLS을 종료함). 또한 게이트웨이(Gateway) 설정에서 인증서, SNI 등을 인가 규칙에 사용할 수 있음. Google Cloud+1	⚠️ 제한적	Cilium이 HTTP L7 정책을 얹을 수 있는 조건들이 있지만, TLS 종료 지점을 제어하지 않거나, SNI 기반 라우팅/조건/인가 조합이 Istio만큼 포괄적이지 않거나 문서상 덜 강조됨.
Fault injection, Retries, Timeouts, Traffic splitting, Canary-routing 등 L7 트래픽 관리	✅ 가능 — Istio는 VirtualService, DestinationRule, Gateway 등을 통해 라우팅, fault injection, retry 정책, timeout 등 정교한 트래픽 제어 가능. Istio+1	⚠️ 제한적 / 기능 일부만 가능	Cilium 문서 중 “L7-Aware Traffic Management” 부분이 있음 but 주로 Envoy 설정을 통해 가능. 예를 들어 circuit breaking은 가능함(CiliumClusterwideEnvoyConfig) docs.cilium.io. 그러나 retry/fault-injection/traffic splitting 같은 Istio의 고급 라우팅 및 복합 조건 설정은 덜 문서화됨, 덜 보편적임.

요약

• Istio는 HTTP 수준(L7)의 요청 내용, 인증서, JWT 클레임, 헤더, 경로, 메서드, 서비스 계정/프린서플 등 다양한 조건을 정책으로 쓸 수 있고, 감사 로깅, 외부 인증자/custom authorizer, fault injection, retries/timeouts, 라우팅 분기, 트래픽 스플리팅처럼 트래픽 관리 측면 기능이 매우 풍부함.
• Cilium은 기본적으로 L3/L4 네트워크 정책 + 필요할 때 L7 (HTTP path, method 등) 지원 + Envoy 프록시 기반 설정 가능하지만, Istio만큼의 복잡한 조건 조합, 외부 authorizer 통합, 감사전용 정책, 혹은 고급 트래픽 제어 기능들은 문서상 제약이 있음.

 

path 정책도 차이

배경 요약

• Istio: AuthorizationPolicy의 paths 필드에서 Exact, Prefix, Suffix, Presence(“값이 비어있지 않은 경우”) 매칭을 지원하고, Istio 1.22 부터는 path template operator ({*}, {**})도 지원됨. 또한 path normalization 기능이 있어서 //, .., 인코딩(%HH), 대소문자 등 처리 방식이 설정 가능. Istio+4Istio+4GitHub+4
• Cilium: CiliumNetworkPolicy의 http 규칙에서 path 필드를 사용할 수 있고, "extended POSIX regex" 매칭을 문서상 언급함. 즉 /public, /path1, /path2$ 등과 같은 정규표현식 패턴 매칭을 허용함. docs.cilium.io+2Medium+2
  단, 복잡한 템플릿 연산자(template operator)나 Istio 스타일의 {**} 등의 특정 문법 지원 여부는 제한적임 또는 문서화되어 있지 않음. 또한 Ingress의 pathType: ImplementationSpecific 사용 시 경로나 우선순위 등에서 버그/제한이 보고됨. GitHub+1

---

비교 표

아래는 경로(path) 정책에서 Istio가 지원하는 것 vs Cilium에서 가능하거나 제한 있는 것들을 나열한 표야.

 

기능 / 속성	Istio에서 가능	Cilium에서 가능 / 제약 있음상세 설명 및 제한 조건
Exact 매칭 (경로가 정확히 일치)	✅ 예. paths: ["/foo/bar"] 등의 exact match 가능. Istio	✅ 예. path: "/public" 처럼 정확히 일치하는 매치 가능. docs.cilium.io
Prefix 매칭 (경로의 시작 부분)	✅ 가능. paths: ["/api*"] 와 같이 prefix wildcard 지원. Istio	✅ 가능. 정규표현식이나 끝에 $ 등을 포함하여 prefix 패턴 매칭 구현 가능. docs.cilium.io
Suffix 매칭 (경로의 끝 부분)	✅ 가능. 예: paths: ["*/suffix"] 또는 *suffix 등. Istio	⚠️ 제한적 / 문서화 약함. 일반적으로 “정규표현식”으로 끝 부분 매칭 가능하지만, Istio처럼 명시적 suffix match 키워드는 없음. 정규표현식 패턴을 써야 함. docs.cilium.io
패턴 또는 정규표현식 (Regex) 매칭	⚠️ 부분적으로 가능. Istio에서는 wildcard, prefix/suffix, 그리고 {*}, {**} 템플릿 연산자 도입됨. 하지만 완전 자유로운 regex는 제한됨(성능/안정성 고려됨). GitHub+2Istio	✅ 가능. Cilium 문서에서 extended POSIX regex 사용 명시됨. path 필드에 정규표현식 패턴 삽입 가능함. docs.cilium.io
템플릿 연산자 (예: {*}, {**} 같은 경로 세그먼트 기반 패턴)	✅ 있음. Istio 1.22+에서 {*}, {**} 연산자 도입됨. 예: /{*}/health, /assets/{**} 등. GitHub	❌ 문서상 명확하게 {*}, {**} 같은 템플릿 기반 연산자 지원 언급 없음. regex 등으로 비슷하게 표현할 수는 있지만 동일 문법/템플릿 기법은 없는 듯.
정규화 (Normalization) (이중 슬래시 //, 점(.)/점 두 개(..), URL 인코딩/디코딩, 대소문자 등)	✅ 상세 지원 있음. multiple slash, dot segments, URL 인코딩/디코딩, 대소문자 매칭 등 정책 강화를 위한 normalization 옵션 있음. Istio	⚠️ 제한 있음. 문서에서 경로 매칭에 대해 정규화(normalization)의 상세 옵션 언급이 적거나 없음. 일부 Ingress의 pathType 동작이 대소문자, slash 중복 등의 edge case에서 예상치 못한 동작 보이는 버그 보고됨. GitHub
부정 매칭 (notPaths / negative path matching)	✅ 가능. notPaths 필드를 이용해 특정 경로 제외할 수 있음. Istio	❌ 문서상 명확한 notPath 같은 키워드 없음. “경로가 없거나 빈 경우 허용/거부” 등은 가능하지만, Istio처럼 notPaths 리스트로 제외하는 기능은 뚜렷히 보이지 않음.
쿼리 스트링(“?…” 부분) 무시 / 포함 여부	✅ Istio에서 paths 비교 시 물음표 이후(query string)는 제거하고 비교됨. 즉 정책 비교에는 query string 제외됨. Istio	⚠️ 문서상 query string 처리 방식이 명확히 정의된 부분 적음. 일반적으로 path 필드만 매칭하고 query string은 포함하지 않는 경우가 많음.
대소문자(case sensitivity)	✅ 일부 normalization/옵션으로 헤더 이름, 경로 등에 대해 대소문자 처리 있음 (예: URL 인코딩, 소문자 변환) Istio	⚠️ 명확히 문서화된 대소문자 무시/자동 변환(normalization) 옵션은 적음. 패턴 매칭/정규표현식 사용 시 case sensitivity가 기본 설정인지 여부 확인 필요.
Path 매칭 우선순위 / 충돌 해결	✅ 명확한 우선순위 규칙 있음. 예: 특정 정책들이 먼저 평가됨. Fritz wildcard vs prefix vs exact 매칭 등. 또한 normalization 옵션이 정책 해석에 영향을 줄 수 있음. Istio	⚠️ 일부 버그/이슈 보고됨. 예: Ingress pathType “ImplementationSpecific”에서 우선순위 문제가 있음. 매칭 여러 path 규칙 있을 때 어느 것이 우선인지는 Ingress와 Envoy 설정에 따라 달라질 수 있고, 문서에서 완전히 투명하지 않음