Certified Kubernetes Security Specialist (CKS) #12 Pod-to-Pod mTLS: Cilium

CKS #11에서 gVisor와 Kata Containers로 컨테이너를 커널 수준에서 격리하는 법을 다뤘습니다. 격리가 Pod 한 개의 피해 범위를 줄이는 일이었다면, 이번 글은 Pod 사이를 오가는 통신 자체를 지키는 일입니다. Minimize Microservice Vulnerabilities도메인의 마지막 주제로, 전송 중 암호화(encryption in transit)와 그 대표 구현인 mTLS를 잡겠습니다.

쿠버네티스의 기본 네트워크는 평평합니다. Pod가 다른 Pod에 보내는 패킷은 별도 설정이 없으면 **평문(plaintext)**으로 노드 사이를 흐릅니다. 같은 클러스터 안이라고 안전한 것이 아닙니다. 노드 간 트래픽을 도청할 수 있는 공격자나, 클러스터 네트워크에 발을 들인 침입자는 평문 패킷을 그대로 읽습니다. 이번 글은 이 평문 문제를 어떻게 암호화로 덮는지, 그리고 그 방식이 NetworkPolicy와 무엇이 다른지를 개념 중심으로 정리하겠습니다.

왜 Pod 간 통신이 평문이면 위험한가 #

마이크로서비스 구조에서 하나의 요청은 여러 Pod를 거칩니다. 프런트엔드 Pod가 인증 서비스에 묻고, 인증 서비스가 사용자 DB에 묻고, 다시 결제 서비스로 넘어가는 식입니다. 이 사이를 오가는 데이터에는 세션 토큰, 비밀번호, 결제 정보 같은 민감한 값이 들어 있습니다.

기본 클러스터에서 이 트래픽은 암호화되지 않습니다. 다음과 같은 상황을 떠올리면 위험이 분명해집니다.

• 노드 간 도청. CNI에 따라 Pod 트래픽이 노드 사이를 평문으로 흐릅니다. 물리 네트워크나 클라우드 VPC 수준에서 패킷을 캡처할 수 있는 공격자는 내용을 그대로 읽습니다.
• 횡적 이동(lateral movement). 공격자가 한 Pod를 장악하면, 같은 네트워크에서 다른 서비스로 향하는 평문 트래픽을 스니핑하거나, 신원 검증 없이 내부 서비스에 직접 연결합니다.
• 신원의 부재. 평문 통신은 상대가 누구인지 검증하지 않습니다. IP 주소만으로는 “정말 그 서비스가 맞는가"를 보장하지 못합니다. IP는 위조되거나 재할당될 수 있습니다.

CKS #2에서 다룬 NetworkPolicy는 이 가운데 누가 누구에게 연결할 수 있는가를 통제합니다. 그러나 NetworkPolicy는 허용된 연결의 내용을 암호화하지 않습니다. 허용된 통신이라도 그 패킷은 여전히 평문입니다. 여기서 전송 중 암호화가 필요해집니다.

NetworkPolicy와 mTLS는 다른 층의 통제 #

CKS에서 가장 헷갈리기 쉬운 지점이 이 둘의 역할 구분입니다. 표로 먼저 정리하겠습니다.

NetworkPolicy는 연결할 수 있는가를 정하고, mTLS는 연결된 통신을 암호화하고 양쪽 신원을 검증합니다. 둘은 대체재가 아니라 보완재입니다. default deny로 통신을 좁히고(NetworkPolicy), 남은 통신을 암호화하고 신원을 거는(mTLS) 것이 in-transit 보안의 두 축입니다.

mTLS가 무엇인가 #

TLS는 클라이언트가 서버의 인증서를 검증하는 단방향 신원 확인입니다. 웹 브라우저가 서버를 믿는 HTTPS가 여기에 해당합니다. **mTLS(mutual TLS)**는 여기서 한 걸음 더 나아가, 양쪽이 서로의 인증서를 검증합니다. 클라이언트도 자신의 인증서를 제시하고, 서버도 그 인증서를 확인합니다.

쿠버네티스 안에서 mTLS는 두 가지를 동시에 제공합니다.

• 암호화(encryption). 두 Pod 사이의 트래픽이 TLS로 암호화되어, 중간에서 가로채도 내용을 읽을 수 없습니다.
• 워크로드 신원(identity). 각 워크로드에 인증서를 발급해, IP가 아니라 인증서로 “이 서비스가 정말 결제 서비스인가"를 검증합니다. 이 신원은 흔히 SPIFFE 같은 표준으로 표현됩니다.

접근법 1: Service Mesh의 사이드카 mTLS #

Pod 간 mTLS를 구현하는 가장 널리 알려진 방식이 Service Mesh입니다. 대표 구현은 Istio와 Linkerd입니다.

핵심 아이디어는 각 Pod 옆에 프록시 컨테이너(사이드카)를 붙이는 것입니다. 애플리케이션 컨테이너는 평소처럼 평문으로 통신한다고 믿지만, 실제로는 같은 Pod 안의 사이드카 프록시가 트래픽을 가로채 상대 Pod의 사이드카와 mTLS로 주고받습니다.

[ app A ] --평문--> [ sidecar A ] ==mTLS 암호화==> [ sidecar B ] --평문--> [ app B ]

이 구조의 특징은 다음과 같습니다.

• 애플리케이션 코드 무변경. 개발자가 TLS를 직접 다루지 않습니다. 메시가 사이드카 주입(injection)으로 mTLS를 투명하게 처리합니다.
• 자동 인증서 관리. 메시의 컨트롤 플레인이 각 워크로드에 인증서를 발급하고 짧은 주기로 갱신(rotation)합니다. 사람이 인증서를 만들 필요가 없습니다.
• L7 정책과 관측성. mTLS 외에도 트래픽 라우팅, 재시도, L7 권한 정책, 분산 추적 같은 기능을 함께 제공합니다.

Istio에서 메시 전체에 mTLS를 강제하는 정책은 개념적으로 다음과 같습니다.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT       # 평문 거부, mTLS만 허용

STRICT 모드는 사이드카가 있는 워크로드 사이의 통신을 mTLS로만 받습니다. 도입 과도기에는 PERMISSIVE(평문,mTLS 둘 다 허용)로 두었다가 점진적으로 STRICT로 옮기는 것이 일반적입니다.

사이드카 방식의 비용 #

Service Mesh는 강력하지만 대가가 있습니다. Pod마다 프록시 컨테이너가 하나씩 더 붙으므로 메모리,CPU 오버헤드가 생기고, 트래픽이 프록시를 한 번 더 거치므로 **지연(latency)**이 늘어납니다. 컨트롤 플레인이라는 운영 대상도 새로 생깁니다. 그래서 “암호화만 필요한가, L7 기능까지 필요한가"가 도입 판단의 갈림길이 됩니다.

접근법 2: Cilium의 투명 암호화 #

암호화가 주된 목적이라면, 메시의 사이드카 없이 CNI 계층에서 노드 간 트래픽을 통째로 암호화하는 방법이 있습니다. 이것이 **Cilium의 투명 암호화(transparent encryption)**입니다.

Cilium은 eBPF 기반 CNI로, NetworkPolicy를 처리하는 데이터 플레인에서 곧바로 암호화를 켤 수 있습니다. 두 가지 백엔드를 제공합니다.

투명 암호화의 핵심은 이름 그대로 투명하다는 점입니다. 애플리케이션도, Pod 매니페스트도 바꾸지 않습니다. Cilium이 노드를 떠나는 Pod 트래픽을 자동으로 암호화하고, 받는 노드에서 복호화합니다. 사이드카가 없으므로 Pod당 프록시 오버헤드도 없습니다.

[ Pod A on node1 ] --> Cilium(암호화) ==WireGuard 터널==> Cilium(복호화) --> [ Pod B on node2 ]

WireGuard 투명 암호화는 Cilium 설정에서 한 줄 수준으로 켜는 개념입니다. 설치 도구에 따라 다르지만, Helm 값으로 표현하면 다음과 같은 형태입니다.

# Cilium 설치 시 (Helm values 개념)
encryption:
  enabled: true
  type: wireguard

켜고 나면 노드 사이를 오가는 Pod 트래픽이 WireGuard로 암호화됩니다. 노드 간 도청 위협이 사라지는 것이 핵심 효과입니다.

Cilium 투명 암호화 vs mTLS #

여기서 한 가지 구분이 중요합니다. WireGuard,IPsec 투명 암호화는 노드 대 노드(node-to-node) 암호화입니다. 트래픽을 암호화하지만, mTLS처럼 워크로드 단위의 상호 신원 검증을 그 자체로 제공하지는 않습니다. 도청은 막지만 “이 연결의 상대 워크로드가 정말 누구인가"를 인증서로 검증하는 일은 별개입니다.

그래서 Cilium은 별도로 mTLS 방향의 기능을 발전시켜 왔습니다. SPIFFE 기반의 워크로드 신원을 도입해, 암호화에 더해 신원 기반 정책까지 사이드카 없이 처리하려는 흐름입니다. 정리하면 다음과 같습니다.

• WireGuard,IPsec 투명 암호화: 노드 간 트래픽 암호화에 집중. 도청 방지가 목적.
• Cilium mTLS,SPIFFE 신원: 워크로드 단위 신원 검증과 정책. 사이드카 없는 mTLS 방향.

CKS 관점에서는 “사이드카 메시(Istio,Linkerd)냐, CNI 내장 암호화(Cilium)냐"라는 두 갈래의 선택지가 있다는 사실과, 각각이 암호화와 신원을 어떻게 다루는지를 구분할 수 있으면 충분합니다.

Cilium에서 L7 통제 한 줄 #

Cilium은 표준 NetworkPolicy를 확장한 CiliumNetworkPolicy로 L7 수준의 통제도 표현합니다. 예를 들어 특정 서비스에 대해 HTTP GET /metrics만 허용하는 정책을 개념적으로 한 조각만 보겠습니다.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-metrics-only
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/metrics"

표준 NetworkPolicy가 포트까지만 통제했다면, CiliumNetworkPolicy는 HTTP 메서드,경로 같은 L7 속성까지 통제합니다. 암호화,신원과는 다른 축이지만, in-transit 보안을 이야기할 때 Cilium이 L3,L4를 넘어 어디까지 닿는지를 보여 주는 예입니다.

CKS 관점: 무엇을 알아야 하는가 #

이 주제에서 CKS가 요구하는 깊이는 세밀한 메시 구성이 아니라 개념과 판단입니다. 다음을 분명히 할 수 있으면 됩니다.

• 왜 필요한가. Pod 간 통신은 기본 평문이고, 노드 간 도청과 횡적 이동에 노출됩니다. 전송 중 암호화로 이 위협을 덮습니다.
• 무엇이 다른가. NetworkPolicy는 연결 허용,차단(L3,L4), mTLS는 암호화와 상호 신원 검증입니다. 둘은 보완 관계입니다.
• 어떤 방식이 있는가. 사이드카 기반 Service Mesh(Istio,Linkerd)의 mTLS, CNI 내장 투명 암호화(Cilium WireGuard,IPsec), 그리고 Cilium의 mTLS,SPIFFE 방향.
• trade-off는 무엇인가. 메시는 강력하지만 사이드카 오버헤드와 운영 부담이 있고, 투명 암호화는 가볍지만 그 자체로는 워크로드 신원 검증을 제공하지 않습니다.

시험 포인트 #

• Pod 간 기본 통신은 평문입니다. 같은 클러스터라고 암호화되는 것이 아닙니다.
• **전송 중 암호화(encryption in transit)**의 대표 구현이 mTLS입니다. mTLS는 암호화와 상호 신원 검증을 함께 제공합니다.
• 단방향 TLS와 mTLS의 차이를 구분합니다. mTLS는 클라이언트도 인증서를 제시합니다.
• NetworkPolicy(L3,L4)와 mTLS(암호화,신원)는 다른 층입니다. NetworkPolicy는 통신을 허용,차단할 뿐 내용을 암호화하지 않습니다. 둘은 함께 씁니다.
• Service Mesh(Istio,Linkerd)는 사이드카 프록시로 애플리케이션 변경 없이 mTLS를 투명하게 처리하고, 인증서를 자동 발급,갱신합니다. 대가는 오버헤드와 운영 부담입니다.
• Cilium은 WireGuard,IPsec 투명 암호화로 노드 간 Pod 트래픽을 사이드카 없이 암호화합니다. 이는 노드 간 암호화이며, 워크로드 신원 검증은 SPIFFE 기반 mTLS 방향으로 별도입니다.
• Istio의 PeerAuthentication에서 STRICT는 mTLS만 허용하고 PERMISSIVE는 평문,mTLS를 함께 허용한다는 차이를 기억합니다.

정리 #

이번 글에서 잡은 것:

• Pod 간 통신은 기본 평문. 노드 간 도청과 횡적 이동에 노출되므로 전송 중 암호화가 필요합니다.
• mTLS는 암호화와 상호 워크로드 신원 검증을 함께 제공합니다. 단방향 TLS와 구분합니다.
• NetworkPolicy와 mTLS는 보완재. 하나는 연결을 통제하고, 하나는 통제된 연결을 암호화하고 신원을 겁니다.
• 두 접근법. 사이드카 기반 Service Mesh(Istio,Linkerd)와 CNI 내장 투명 암호화(Cilium WireGuard,IPsec), 그리고 Cilium의 mTLS,SPIFFE 방향.
• CKS는 상세 구성보다 개념과 trade-off를 묻습니다. 왜 암호화하는가, 무엇이 다른가, 어떤 비용이 있는가를 설명할 수 있어야 합니다.

이로써 Minimize Microservice Vulnerabilities도메인(#9〜#12)을 마무리합니다. PSA로 위험한 Pod를 막고, Secrets를 암호화하고, 워크로드를 격리하고, 통신을 암호화하는 네 갈래로 마이크로서비스의 공격 표면을 줄였습니다.

다음: Minimal images #

워크로드를 둘러싼 통제는 여기까지입니다. 다음 도메인 Supply Chain Security는 컨테이너 이미지 자체를 안전하게 만드는 일로 넘어갑니다.

#13 Minimal images: distroless, scratch (Supply Chain)에서는 이미지에 들어가는 패키지를 최소로 줄여 공격 표면 자체를 좁히는 법, distroless와 scratch 베이스 이미지의 차이, 셸과 패키지 매니저를 뺀 이미지가 왜 더 안전한지, 그리고 멀티 스테이지 빌드로 최종 이미지를 가볍게 만드는 패턴까지 직접 만들어 보며 정리하겠습니다.