[Cilium] 쿠버네티스 보안의 핵심, Service Account 기반 네트워크 정책 완벽 가이드 🛡️

안녕하세요! 오늘은 쿠버네티스 네트워크 보안의 "끝판왕"이라 불리는 Cilium을 활용해 더 안전하고 직관적인 보안 정책을 수립하는 방법에 대해 깊이 파보려 합니다.

특히, 단순히 Label(레이블)만 사용하는 것이 아니라 Service Account(서비스 어카운트)를 활용해 정책을 짜는 방법과 그 이유에 대해 상세히 정리해 드립니다. 🚀

---

🧐 왜 Label만으로는 부족할까요?

기본적인 쿠버네티스 NetworkPolicy는 파드에 붙어 있는 Label(app: frontend 등)을 기준으로 트래픽을 허용하거나 차단합니다. 하지만 여기에는 치명적인 보안 허점이 존재할 수 있습니다.

1. 위조 가능성 (Spoofing): 개발자나 공격자가 악의적으로 파드를 띄우면서 app: frontend라는 라벨을 임의로 붙인다면? 방화벽은 이를 구분하지 못하고 통과시켜 버립니다. 😱
2. 관리의 복잡함: 파드의 버전이 바뀌거나 배포 전략이 바뀔 때마다 라벨 관리가 엉키기 쉽습니다.

💡 해결책: Service Account (SA) 기반 정책

Cilium은 ID(Identity) 기반 보안을 제공합니다. 파드가 생성될 때 할당되는 Service Account는 쿠버네티스 RBAC(Role-Based Access Control)에 의해 엄격하게 관리되므로, 라벨보다 훨씬 신뢰할 수 있는 식별자입니다.

즉, "이 라벨을 가진 파드"가 아니라 "이 신분증(SA)을 가진 파드"만 통과시키겠다는 뜻입니다.

---

🛠️ 작동 원리: io.kubernetes.serviceaccount.name

Cilium은 파드가 생성될 때 해당 파드의 Service Account 정보를 읽어와 내부적으로 특수한 라벨로 변환하여 관리합니다.

• 키(Key): io.kubernetes.serviceaccount.name
• 값(Value): 실제 Service Account 이름 (예: frontend-sa)

우리는 이 특수 라벨을 CiliumNetworkPolicy (CNP)에서 사용하여 아주 정교한 규칙을 만들 수 있습니다.

---

📝 실전 설정 가이드 (YAML 예제)

상황을 가정해 봅시다.

목표: 오직 frontend-sa라는 Service Account를 사용하는 파드만이 backend 파드에 접근할 수 있어야 합니다.

1. CiliumNetworkPolicy 작성

YAML

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "secure-backend-access"
  namespace: "default"
spec:
  # 1️⃣ 목적지 설정: 누구를 보호할 것인가? (Backend)
  endpointSelector:
    matchLabels:
      app: backend

  # 2️⃣ 인바운드 규칙 (Ingress): 누가 들어올 수 있는가?
  ingress:
  - fromEndpoints:
    - matchLabels:
        # 3️⃣ 핵심 포인트! Service Account 이름을 지정
        io.kubernetes.serviceaccount.name: "frontend-sa"

        # (선택 사항) 같은 네임스페이스임을 명시하고 싶다면
        io.kubernetes.pod.namespace: "default"

🔍 상세 분석

• endpointSelector: 정책이 적용될 대상입니다. 여기서는 app: backend 라벨을 가진 파드들이 보호 대상이 됩니다.
• fromEndpoints: 접근을 허용할 소스(출발지)를 정의합니다.
• io.kubernetes.serviceaccount.name: 여기가 마법이 일어나는 곳입니다! 🎩 일반적인 app 라벨 대신, 쿠버네티스가 보증하는 SA 이름을 조건으로 걸었습니다. 이제 아무리 app: frontend 라벨을 위조해서 붙여도, SA가 frontend-sa가 아니라면 접근이 차단됩니다.

---

🌟 Service Account 정책의 장점 요약

구분	일반 NetworkPolicy (Label)	Cilium CNP (Service Account)
식별 기준	사용자가 임의로 붙인 Label	K8s가 인증한 Service Account
보안 강도	낮음 (라벨 위조 쉬움)	높음 (RBAC로 통제됨)
가시성	IP/Label 위주	애플리케이션/ID 위주
적용 예	단순 격리	제로 트러스트(Zero Trust) 구현

---

🍯 꿀팁: 네임스페이스가 다르다면?

만약 frontend 팀의 네임스페이스(team-a)에 있는 SA가 backend 네임스페이스(team-b)로 접근해야 한다면 어떻게 할까요? Cilium은 네임스페이스 라벨도 함께 조합할 수 있습니다.

YAML

  - fromEndpoints:
    - matchLabels:
        io.kubernetes.serviceaccount.name: "frontend-sa"
        io.kubernetes.pod.namespace: "team-a"  # 👈 네임스페이스까지 지정!

이렇게 하면 team-a 네임스페이스에 있는 frontend-sa 서비스 어카운트만 정확하게 허용하게 됩니다.

---

🏁 마치며

Cilium을 사용한다면, 더 이상 불안한 Label에만 의존하지 마세요. Service Account를 활용하면 인프라 레벨의 보안 정책을 애플리케이션의 인증 체계(RBAC)와 결합하여 훨씬 강력한 Defense-in-Depth(심층 방어) 전략을 구축할 수 있습니다.

지금 바로 여러분의 클러스터 정책을 점검해 보세요! 😉

---