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

🛡️ 1. 네트워크 폴리시: "기본은 차단, 허용은 화이트리스트"
쿠버네티스의 네트워크 보안 철학은 '제로 트러스트(Zero Trust)'입니다.
① 기본 작동 방식
네트워크 폴리시는 기본적으로 화이트리스트(Allow-list) 방식입니다.
- 아무런 정책이 없을 때는 모든 통신이 허용됩니다.
- 하지만 특정 파드에 정책을 하나라도 적용하는 순간, 그 파드는 "명시적으로 허용된 것 외에는 모두 차단"되는 폐쇄적인 상태로 바뀝니다.
② Ingress와 Egress
- Ingress (인그레스): 파드로 들어오는 트래픽을 통제합니다. (예: "누가 내 DB에 들어올 수 있지?")
- Egress (이그레스): 파드에서 나가는 트래픽을 통제합니다. (예: "내 분석 파드가 허락 없이 외부 인터넷으로 데이터를 보내나?")
📍 2. 트래픽을 선별하는 3가지 필터 (Selectors)
네트워크 폴리시는 다음 세 가지를 조합하여 "누구를 통과시킬지" 결정합니다.
- podSelector: 같은 클러스터 내의 특정 라벨을 가진 파드들. (예:
role: frontend) - namespaceSelector: 특정 네임스페이스에 속한 모든 파드들. (예:
ns: public-zone) - 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그룹 시스템이라면 반드시 Calico나 Cilium 같이 네트워크 폴리시를 지원하는 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'은 어떻게 설정하고 관리해?"
'1. 개발 > 1.6. 쿠버네티스 (Kubernetes,K8s)' 카테고리의 다른 글
| 'RBAC(Role-Based Access Control)'의 Role, ClusterRole, Binding 개념은 어떻게 연결돼? (0) | 2026.02.12 |
|---|---|
| 'Job'과 'CronJob'은 어떻게 설정하고 관리해? (0) | 2026.02.11 |
| 'ExternalName Service'와 'Endpoints'는 어떤 원리로 작동해? (0) | 2026.02.11 |
| (NodeSelector/Affinity), (Taints/Tolerations) '스케줄링 기법' (0) | 2026.02.11 |
| 'Resource Requests'와 'Limits', 'QoS(Quality of Service) 클래스' 설정 (0) | 2026.02.11 |