isito 와 cilium path 정책 차이

 

 

1.패턴 매칭 방식

Cilium - 정규식 지원

http:

• path: "/api/v[0-9]+/users/[a-zA-Z0-9-]+" # 정규식
• path: ".*\\.(jpg|png|gif)$" # 파일 확장자

Istio - Glob 패턴만

operation: paths: ["/api//users/"] # 와일드카드만

정규식 지원하지 않음

2. 정책 우선순위 처리

Cilium - 순서대로 첫 매칭

ingress:

• rules: http:
  • path: "/admin" # 먼저 매칭되면 허용
  • path: "/admin/.*" # 두 번째 규칙은 무시됨

Istio - DENY > ALLOW

복수 정책이 있어도 DENY가 우선

• ALLOW: "/admin"
• DENY: "/admin/*"

결과: DENY 승리

3.헤더 및 조건부 매칭

Cilium - 정규식 기반 헤더 매칭

http:

• path: "/api/.*" headers:
  • "Authorization: Bearer [a-zA-Z0-9.-]+"

Istio - 키-값 정확 매칭 + 조건부 로직

operation: paths: ["/api/*"] when:

• key: request.headers[authorization] values: ["Bearer *"]
• key: source.labels[app] values: ["frontend"]

4. 성능 및 처리 위치

Cilium (eBPF in kernel)

Client → Kernel eBPF (path check) → Pod

지연: ~0.1ms

Istio (Envoy proxy)

Client → Pod → Envoy Sidecar → App Container

지연: ~1-2ms 추가

5. 실제 테스트로 확인되는 차이

정규식 테스트

Cilium에서만 가능

• path: "/status/[0-9]{3}" # /status/200, /status/404만 매칭

Istio는 불가능 → 다음과 같이 해야 함

• paths: ["/status/200", "/status/404", "/status/500"] # 모든 코드 나열

복잡한 조건부 로직

Istio가 더 강력

when:

• key: source.ip values: ["10.0.0.0/8"]
• key: request.time.hour values: ["9", "10", "11"] # 업무시간만 허용

Cilium은 이런 시간/IP 조건부 로직이 제한적

결론

Path 제어 기본 기능은 비슷하지만:

• Cilium: 성능 우수, 정규식 강력, 단순한 우선순위
• Istio: 복합 조건 로직 강력, JWT 통합, 복잡한 인가 시나리오