K05: Network Segmentation — 네트워크 격리

쿠버네티스 클러스터는 기본적으로 ‘flat network’ 구조를 가집니다. 별도의 설정을 하지 않으면 클러스터 내의 모든 Pod가 서로 자유롭게 통신할 수 있습니다. 이는 공격자가 Pod 하나만 장악하면 다른 Pod로 넘나드는 **횡적 이동(lateral movement)**이 매우 쉽다는 뜻입니다. K05는 NetworkPolicy로 이 통신 경로를 제어하는 법을 다룹니다.

미션: Pod 간 불필요한 통신 차단

네트워크 정책이 없는 환경에서는 공격자가 침투한 Pod에서 내부망의 다른 서비스(예: 데이터베이스, 관리자 페이지)를 직접 스캔하고 공격할 수 있습니다.

1. 취약한 상태 (vulnerable.yaml)

NetworkPolicy가 존재하지 않거나, 기본적으로 모든 트래픽을 허용하는 상태입니다.

# 정책이 없으므로, 클러스터 내의 모든 Pod는 서로 통신 가능
# 공격자는 Pod A에 침투한 뒤, 내부 네트워크를 통해 Pod B(데이터베이스)로 즉시 접근 가능

분석: 공격자가 웹 서버 Pod 하나만 뚫어도, 동일한 클러스터 안에 있는 데이터베이스나 다른 민감한 서비스로 직접 네트워크 연결을 시도할 수 있습니다. 방화벽이 없는 것과 같습니다.

2. 해결책 코드 (fixed.yaml)

NetworkPolicy로 화이트리스트(허용 목록) 기반의 통신만 허용합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-db
spec:
  podSelector:
    matchLabels:
      app: database  # ✅ 대상: 데이터베이스 Pod
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web-server # ✅ 오직 'web-server' Pod에서의 접속만 허용

분석: 이제 데이터베이스 Pod는 오직 web-server 레이블을 가진 Pod로부터의 접근만 허용합니다. 공격자가 다른 Pod(예: 관리자 Pod)를 장악하더라도, 네트워크 정책에 의해 데이터베이스 접근이 원천 차단됩니다.

실습: 공격 → 방어 검증

1) 공격 — 임의 Pod에서 데이터베이스 포트로 직접 접속

kubectl exec -it attacker-pod -- curl -m 3 db-service:5432
# 연결 성공 — 정책이 없어 모든 Pod 간 통신이 열려 있음

2) 방어 — NetworkPolicy 적용 후 동일한 시도

kubectl apply -f fixed.yaml
kubectl exec -it attacker-pod -- curl -m 3 db-service:5432
# curl: (28) Connection timed out after 3000 milliseconds

web-server 레이블이 없는 Pod에서의 접근은 타임아웃으로 차단됩니다.

체크리스트

• 클러스터 CNI가 NetworkPolicy를 실제로 지원하는가 (Calico, Cilium 등)
• 네임스페이스별로 기본 deny-all 정책이 있고, 그 위에 필요한 통신만 화이트리스트로 추가하는가
• 데이터베이스·내부 관리 서비스처럼 민감한 Pod에 ingress 제한이 걸려 있는가
• egress 방향도 제어하는가 (침투한 Pod가 외부로 데이터를 유출하는 경로 차단)

“클러스터 내부망이라고 해서 모두 다 연결되어 있을 필요는 없다"는 제로 트러스트(Zero Trust)의 핵심 원칙을 실습하는 과정입니다. K01부터 K05까지는 컨테이너·권한·시크릿·정책·네트워크로 이어지는 워크로드 중심의 방어였다면, 다음 미션(K06: Exposed Components)부터는 클러스터 자체의 관리 인터페이스가 외부에 노출되는 문제로 시야를 넓힙니다.