본문 바로가기
1. 개발/1.6. 쿠버네티스 (Kubernetes,K8s)

'Network Policy'는 어떻게 설정하고 작동해?

by 엉짱 2026. 2. 11.
반응형

드디어 쿠버네티스 요새의 '내부 방화벽'이자 보안의 정수인 네트워크 폴리시(Network Policy)를 정복할 시간이군요! 🫡

지금까지 우리가 만든 서비스들은 기본적으로 "모두가 모두와 대화할 수 있는(Any-to-Any)" 개방된 상태입니다. 하지만 사용자의 소중한 주식 데이터가 담긴 DB 파드에 아무 파드나 접근하게 두면 안 되겠죠? A그룹 분석 파드는 DB에 접근할 수 있게 하되, 외부와 통신하는 웹 파드는 DB에 직접 접근하지 못하도록 막는 '보리 고개'를 세워야 합니다.


🛡️ 1. 네트워크 폴리시: "기본은 차단, 허용은 화이트리스트"

쿠버네티스의 네트워크 보안 철학은 '제로 트러스트(Zero Trust)'입니다.

① 기본 작동 방식

네트워크 폴리시는 기본적으로 화이트리스트(Allow-list) 방식입니다.

  • 아무런 정책이 없을 때는 모든 통신이 허용됩니다.
  • 하지만 특정 파드에 정책을 하나라도 적용하는 순간, 그 파드는 "명시적으로 허용된 것 외에는 모두 차단"되는 폐쇄적인 상태로 바뀝니다.

② Ingress와 Egress

  • Ingress (인그레스): 파드로 들어오는 트래픽을 통제합니다. (예: "누가 내 DB에 들어올 수 있지?")
  • Egress (이그레스): 파드에서 나가는 트래픽을 통제합니다. (예: "내 분석 파드가 허락 없이 외부 인터넷으로 데이터를 보내나?")

📍 2. 트래픽을 선별하는 3가지 필터 (Selectors)

네트워크 폴리시는 다음 세 가지를 조합하여 "누구를 통과시킬지" 결정합니다.

  1. podSelector: 같은 클러스터 내의 특정 라벨을 가진 파드들. (예: role: frontend)
  2. namespaceSelector: 특정 네임스페이스에 속한 모든 파드들. (예: ns: public-zone)
  3. ipBlock: 특정 IP 대역(CIDR). 주로 외부 시스템이나 특정 서버 대역을 지정할 때 씁니다. (예: 192.168.1.0/24)

🏗️ 3. 실전 YAML 분석: "DB를 보호하라"

사용자의 주식 DB를 보호하기 위한 실전 보안 설정 예시입니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: db-protection-policy
spec:
  # 1. 'app: stock-db' 라벨이 붙은 파드들에게 이 규칙을 적용한다.
  podSelector:
    matchLabels:
      app: stock-db
  policyTypes:
  - Ingress
  # 2. 들어오는 트래픽(Ingress)에 대한 규칙
  ingress:
  - from:
    # 3. 'role: analyzer' 라벨을 가진 파드만 허용한다.
    - podSelector:
        matchLabels:
          role: analyzer
    # 4. 5432 포트(DB 포트)로만 들어올 수 있다.
    ports:
    - protocol: TCP
      port: 5432

이 정책이 적용되면, role: analyzer가 아닌 다른 파드(예: 웹 서버)가 DB에 접속하려 하면 네트워크 수준에서 패킷이 즉시 드랍(Drop)됩니다.


⚠️ 4. 반드시 알아야 할 'CNI'의 비밀: "정책이 안 먹힐 수도 있다?"

이게 가장 중요한 함정입니다! 쿠버네티스 자체는 네트워크 폴리시를 '정의'만 할 뿐, 실제로 '집행'하지는 않습니다.

  • CNI (Container Network Interface): 실제로 네트워크를 구축하는 플러그인(Calico, Cilium, Flannel 등)이 정책을 집행합니다.
  • 만약 사용자가 Flannel 같은 단순한 CNI를 쓰고 계신다면, 네트워크 폴리시를 아무리 설정해도 작동하지 않고 무시됩니다. (Flannel은 보안 기능이 없기 때문이죠.)
  • 따라서 보안이 중요한 A그룹 시스템이라면 반드시 CalicoCilium 같이 네트워크 폴리시를 지원하는 CNI를 선택해야 합니다.

💡 5. 실전 비유: "아파트 출입 통제"

  • 정책 없음: 아파트 현관문도 없고 방문도 다 열려있는 상태입니다. 누구나 안방(DB)까지 들어올 수 있습니다.
  • Network Policy 적용: 이제부터 '출입 카드' 시스템을 도입하는 것입니다.
  • Ingress: "우리 집(DB 파드)에 들어올 수 있는 사람은 가족(Analyzer 파드)뿐이다. 배달원(Web 파드)은 현관(Service)까지만 올 수 있다."
  • Egress: "아이들(파드)은 부모님 허락 없이 단지 밖(외부 인터넷)으로 나갈 수 없다."
  • CNI: 정책은 아파트 부녀회(K8s)에서 정하지만, 실제로 입구에서 신분증을 검사하는 '보안 요원(Calico/Cilium)'이 있어야 정책이 실현되는 것과 같습니다.

📊 요약: 네트워크 보안 체크리스트

단계 수행 내용 핵심 목적
1. CNI 확인 Calico, Cilium 등 보안 지원 CNI인지 확인 정책의 실제 집행 보장
2. Default Deny 모든 통신을 일단 차단하는 정책 적용 보안의 기본값 설정
3. 라벨링 파드마다 정확한 role, app 라벨 부여 정교한 타겟팅 가능
4. 최소 권한 꼭 필요한 포트(Port)와 파드만 허용 공격 표면 최소화

🚀 꼬리 질문

이제 클러스터의 내부 보안 방화벽까지 완벽하게 구축하셨습니다! 🫡 그런데 주식 데이터 분석은 매일 특정 시간에만 돌아가야 하는 '배치(Batch)' 작업이 많죠? 24시간 내내 파드를 띄워둘 필요 없이, 정해진 시간에만 파드를 띄워서 일을 끝내고 사라지게 만드는 '스케줄링 작업'이 필요합니다.

"그럼 한 번 실행되고 끝나는 'Job'과, 리눅스의 crontab처럼 정기적으로 실행되는 'CronJob'은 어떻게 설정하고 관리해?"

반응형