Cilium mTLS 암호화는 애플리케이션을 변경하거나 추가 네트워킹 스택을 도입하지 않고도 Kubernetes에서 Pod 간 트래픽에 대해 mTLS(투명한 상호 TLS) 암호화 및 인증을 제공합니다.
트래픽을 교환하기 전에 원본 워크로드와 대상 워크로드를 모두 암호화하여 인증합니다. 이 방법을 사용하면 Kubernetes 워크로드에 대한 제로 트러스트 네트워킹 모델을 사용할 수 있습니다.
모든 암호화 및 인증은 애플리케이션 계층 아래에서 수행되므로 mTLS의 이점을 활용하기 위해 워크로드를 수정, 다시 빌드 또는 다시 시작할 필요가 없습니다.
AKS용 Cilium mTLS 암호화는 ACNS(Advanced Container Networking Services) 기능 집합의 일부이며 해당 구현은 Cilium을 기반으로 합니다.
중요합니다
AKS 미리 보기 기능은 셀프 서비스에서 사용할 수 있습니다(옵트인 방식). 미리 보기는 "있는 그대로" 및 "사용 가능한 상태로" 제공되며 서비스 수준 계약 및 제한적 보증에서 제외됩니다. AKS 미리 보기의 일부는 고객 지원팀에서 최선을 다해 지원합니다. 따라서 이러한 기능은 프로덕션 용도로 사용할 수 없습니다. 자세한 내용은 다음 지원 문서를 참조하세요.
아키텍처
높은 수준에서 Cilium mTLS는 ID 발급, 투명한 트래픽 차단 및 워크로드 수준 암호화 적용을 결합하여 트래픽을 보호합니다.
각 워크로드에는 네임스페이스 및 ServiceAccount와 같은 Kubernetes 특성에서 파생된 암호화 ID가 할당됩니다. Pod 간 TCP 트래픽이 시작되면 트래픽이 노드 수준에서 투명하게 가로채집니다. 그러면 트래픽이 인증되고 대상 워크로드로 전달되기 전에 상호 TLS를 사용하여 암호화됩니다.
시스템은 다음 세 가지 협력 구성 요소로 구성됩니다.
- SPIRE - 워크로드 ID 및 인증서 발급을 제공합니다.
- ztunnel - 데이터 평면에서 mTLS를 적용합니다.
- Cilium - 포트 15001에서 아웃바운드 트래픽을 ztunnel로 리디렉션하는 iptables 규칙을 설치합니다.
이러한 구성 요소를 함께 사용하여 인증 및 암호화가 클러스터 전체에서 투명하고 일관되게 수행되도록 합니다.
ID 및 인증 모델
Cilium mTLS는 SPIFFE 워크로드 ID를 기반으로 상호 인증을 사용합니다.
각 워크로드에는 다음에서 파생된 SPIFFE ID(SVID)가 할당됩니다.
- Kubernetes 네임스페이스
- Kubernetes ServiceAccount
워크로드가 연결을 시작하는 경우:
- 원본 ztunnel은 워크로드에 대한 유효한 SVID를 검색합니다.
- 대상 ztunnel은 제공된 ID의 유효성을 검사합니다.
- 양측은 트래픽이 흐르기 전에 상호 확인을 완료합니다.
인증 결정은 네트워크 위치가 아닌 워크로드 ID를 기반으로 합니다. 이 디자인은 다음을 보장합니다.
- 인증된 워크로드만 통신할 수 있습니다.
- 정체성은 재예약 및 확장 과정에서 일관성을 유지합니다.
- 신뢰는 IP 주소 지정 또는 네트워크 토폴로지에서 종속되지 않습니다.
암호화 흐름
인증에 성공하면 트래픽이 상호 TLS를 사용하여 보호됩니다.
- Pod 네트워크 네임스페이스 내에서 가로채진 트래픽이 로컬 ztunnel 인스턴스로 리디렉션되었습니다.
- 원본 ztunnel은 대상 ztunnel을 사용하여 mTLS 세션을 시작합니다.
- 인증서가 교환되고 유효성이 검사됩니다.
- 애플리케이션 데이터는 전송 전에 암호화됩니다.
- 대상 ztunnel은 트래픽의 암호를 해독하고 대상 Pod에 전달합니다.
등록된 Pod의 모든 패킷은 암호화됩니다. 일반 텍스트 창이 없고 삭제된 첫 번째 패킷이 없습니다. 연결은 mTLS 터널이 설정될 때까지 ztunnel에 의해 인라인으로 유지된 다음, 트래픽이 HBONE(HTTP/2 CONNECT) 터널을 통해 양방향으로 흐릅니다.
핵심 구성 요소
SPIRE(ID 및 신뢰)
SPIRE(SPIFFE 런타임 환경)는 워크로드 ID 및 인증서 관리를 담당합니다. SPIRE에는 SPIRE 서버와 SPIRE 에이전트의 두 가지 주요 구성 요소가 있습니다.
SPIRE 서버는 클러스터 CA(인증 기관)의 역할을 합니다. ID를 받을 수 있는 워크로드에만 수명이 짧은 X.509 인증서(SVID)를 발급합니다. Kubernetes 네이티브 증명을 사용하여 IP 주소와 같은 네트워크 속성 대신 네임스페이스 및 ServiceAccount와 같은 특성에 ID를 바인딩합니다.
각 노드에서 SPIRE 에이전트는 SPIRE 서버에 노드를 증명하고 로컬 워크로드를 대신하여 인증서를 검색합니다. 워크로드는 SPIRE 에이전트와만 통신하며 SPIRE 서버와 직접 통신하지 않습니다.
SPIRE는 모든 워크로드 ID가 다음과 같은지 확인합니다.
- 암호화를 통해 확인할 수 있습니다.
- 자동으로 발급 및 갱신됩니다.
- IP 주소가 아닌 Kubernetes 기본 형식에 바인딩됩니다.
- 파드 재시작 및 재배치 이벤트에도 안정적입니다.
이 ID 기반은 강력한 토폴로지 독립적 신뢰 결정을 가능하게 합니다.
Ztunnel(mTLS 데이터 평면)
Ztunnel은 워크로드 간에 mTLS를 적용하는 간단한 노드 수준 계층 4 프록시입니다. 노드당 하나의 인스턴스가 있는 DaemonSet으로 실행되므로 Pod당 사이드카 프록시가 필요하지 않습니다.
워크로드가 TCP 연결을 시작하면 ztunnel은 피어 노드의 ztunnel 인스턴스와 상호 인증된 TLS 세션을 설정합니다. SPIRE에서 가져온 인증서를 사용하여 트래픽이 흐르도록 허용하기 전에 연결의 양쪽을 인증합니다.
Ztunnel은 다음 보증을 적용합니다.
- 연결의 양쪽에 유효한 워크로드 인증서가 있어야 합니다.
- 인증서는 클러스터 신뢰 도메인에 대해 확인됩니다.
- 트래픽은 항상 유선으로 암호화됩니다.
- 등록된 워크로드에는 일반 텍스트 대체가 허용되지 않습니다.
노드 수준에서 mTLS 적용을 중앙 집중화하여 ztunnel은 Pod당 작업 오버헤드를 증가하지 않고 강력한 보안 속성을 제공합니다.
Cilium (리디렉션 규칙 및 Pod 등록)
Cilium은 mTLS를 애플리케이션에 투명하게 만드는 역할을 담당합니다.
네임스페이스에 "io.cilium/mtls-enabled=true"라는 레이블이 지정되면 Cilium 에이전트는 해당 네임스페이스에 모든 Pod를 등록합니다. 각 Pod의 네트워크 네임스페이스를 입력하고 포트 15001에서 아웃바운드 트래픽을 ztunnel로 리디렉션하는 iptables 규칙을 설치합니다.
또한 Cilium은 Pod UID와 같은 워크로드 메타데이터를 ztunnel에 전달하고 Cilium 운영자와 통합하여 SPIRE에 워크로드 ID를 등록합니다.
애플리케이션의 관점에서 통신은 표준 TCP 소켓을 계속 사용합니다. 암호화 및 인증은 완전히 애플리케이션 계층 아래에 적용되며 코드를 변경할 필요 없습니다.
범위 및 신뢰 경계
네임스페이스 등록
Cilium mTLS는 네임스페이스 수준에서 옵트인 및 범위가 지정됩니다. mTLS 적용을 사용하려면 네임스페이스에 명시적으로 레이블을 지정해야 합니다. 사용하도록 설정하면 해당 네임스페이스 내의 모든 Pod에는 필수 인증 및 암호화가 적용됩니다.
등록되지 않은 네임스페이스의 Pod는 영향을 받지 않습니다. 이 설계를 통해 환경 간에 증분 롤아웃 및 단계적 채택이 가능합니다.
적용 모델
암호화는 두 Pod가 모두 등록된 경우에만 적용됩니다. 등록된 워크로드와 등록되지 않은 워크로드 간의 트래픽은 연결 문제 또는 하드 오류를 일으키지 않고 일반 텍스트로 계속됩니다.
| 출처 | 목적지 | 결과 |
|---|---|---|
| 등록됨 | 등록됨 | 암호화됨 (HBONE을 통해 mTLS) |
| 등록됨 | 등록되지 않음 | 일반 텍스트 통과 |
| 등록되지 않음 | 등록됨 | 일반 텍스트(ztunnel로 캡처되지만 암호화되지 않음) |
| 등록되지 않음 | 등록되지 않음 | 일반 Cilium 데이터 경로(ztunnel 개입 없음) |
고려사항 및 제한사항
- 이 기능은 ACNS(Advanced Container Networking Services) 를 사용하도록 설정된 Cilium에서 구동하는 Azure CNI를 사용하는 클러스터에서만 사용할 수 있습니다.
- mTLS는 네임스페이스 수준에서 사용하도록 설정됩니다. 등록된 네임스페이스의 모든 Pod는 mTLS에 참여합니다. Pod 수준 옵트인 또는 옵트아웃은 지원되지 않습니다.
- Cilium mTLS는 현재 TCP 기반의 Pod-to-Pod 트래픽을 보호합니다. 현재는 UDP를 비롯한 다른 프로토콜을 암호화하거나 인증하지 않습니다.
- 현재 단계에서는 MTLS에서 L4/L7 네트워크 정책 적용이 지원되지 않습니다.
- 사용자 지정 CA를 가져올 수 없습니다. SPIRE는 클러스터 인증 기관 역할을 하며 인증서 발급 및 회전을 관리합니다.
- 동일한 클러스터에서 mTLS와 WireGuard를 모두 사용하도록 설정하는 것은 지원되지 않습니다.
- Istio 및 Cilium mTLS 암호화를 모두 사용하도록 설정하는 것은 지원되지 않습니다.
- 클러스터 간 트래픽에 대한 mTLS 암호화는 지원되지 않습니다.
- 통합을 위해서는 커널에서 iptable 지원이 필요하며 iptable을 지원하지 않는 환경(예: 최소 컨테이너 런타임)과 함께 사용할 수 없습니다.
- 네트워크 네임스페이스 경로가 없는 Pod(예: 호스트 네트워크 Pod)는 ztunnel에 등록할 수 없으며 등록 프로세스 중에 제외됩니다.
가격
중요합니다
고급 컨테이너 네트워킹 서비스는 유료 제품입니다. 가격 책정에 대한 자세한 내용은 고급 컨테이너 네트워킹 서비스 - 가격 책정을 참조하세요.
다음 단계
AKS에서 Cilium mTLS 암호화 를 적용하는 방법을 알아봅니다.
AKS(Azure Kubernetes Service)용 고급 컨테이너 네트워킹 서비스에 대한 자세한 내용은 AKS(Azure Kubernetes Service)용 고급 컨테이너 네트워킹 서비스란?을 참조하세요.