NetworkPolicy 방화벽 완벽 가이드

Kubernetes 클러스터에서 파드 간 네트워크 트래픽을 제어하는 NetworkPolicy의 핵심 개념과 실무 활용법을 다룹니다. 초급 개발자도 쉽게 이해할 수 있도록 방화벽 규칙 설정부터 CNI 플러그인까지 단계별로 설명합니다.

---

목차

1. NetworkPolicy_개념
2. Ingress_규칙_설정
3. Egress_규칙_설정
4. 네임스페이스_간_통신_제어
5. 기본_거부_정책
6. CNI_플러그인과_NetworkPolicy

---

1. NetworkPolicy 개념

어느 날 김개발 씨가 쿠버네티스 클러스터를 운영하던 중 이상한 현상을 발견했습니다. 개발 환경의 파드가 운영 환경의 데이터베이스에 접속하고 있었던 것입니다.

"어떻게 이런 일이 가능하지?" 보안 사고가 날 뻔한 아찔한 순간이었습니다.

NetworkPolicy는 쿠버네티스에서 파드 간의 네트워크 트래픽을 제어하는 방화벽 규칙입니다. 마치 아파트 단지의 출입 통제 시스템처럼, 누가 어떤 파드에 접근할 수 있는지를 명확하게 정의합니다.

이것을 제대로 설정하면 클러스터 내부에서도 철저한 네트워크 보안을 유지할 수 있습니다.

다음 코드를 살펴봅시다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-server-policy
  namespace: production
spec:
  # 정책을 적용할 파드 선택
  podSelector:
    matchLabels:
      app: api-server
  # 정책 유형: 인바운드와 아웃바운드 모두 제어
  policyTypes:
    - Ingress
    - Egress
  # 인바운드 규칙: 프론트엔드에서만 접근 허용
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend

김개발 씨는 입사 6개월 차 DevOps 엔지니어입니다. 오늘도 열심히 쿠버네티스 클러스터를 모니터링하던 중, 보안팀에서 긴급 연락이 왔습니다.

"개발 환경 파드에서 운영 DB로 트래픽이 감지됐어요!" 가슴이 철렁 내려앉은 김개발 씨는 곧바로 네트워크 로그를 확인했습니다. 분명히 별도의 네임스페이스로 분리했는데, 어떻게 이런 일이 가능했던 걸까요?

선배 개발자 박시니어 씨가 다가와 상황을 파악합니다. "아, NetworkPolicy를 설정하지 않았군요.

쿠버네티스는 기본적으로 모든 파드 간 통신을 허용해요." 그렇다면 NetworkPolicy란 정확히 무엇일까요? 쉽게 비유하자면, NetworkPolicy는 마치 회사 건물의 출입 통제 시스템과 같습니다.

사원증이 있어야 특정 층에 들어갈 수 있고, 권한에 따라 접근 가능한 구역이 달라지는 것처럼요. NetworkPolicy도 라벨이라는 사원증을 기반으로 어떤 파드가 어떤 파드에 접근할 수 있는지를 결정합니다.

NetworkPolicy가 없던 시절, 정확히 말하면 NetworkPolicy를 설정하지 않은 클러스터에서는 어떤 일이 벌어질까요? 모든 파드가 서로 자유롭게 통신할 수 있습니다.

개발 환경의 테스트 서버가 운영 환경의 데이터베이스에 접근할 수 있고, 외부에서 침투한 악성 파드가 내부 서비스를 마음대로 탐색할 수 있습니다. 이것은 마치 잠금장치 없는 아파트와 같습니다.

바로 이런 보안 위험을 방지하기 위해 NetworkPolicy가 필요합니다. NetworkPolicy를 설정하면 제로 트러스트 보안 모델을 구현할 수 있습니다.

명시적으로 허용하지 않은 모든 트래픽은 차단됩니다. 또한 마이크로세그멘테이션을 통해 서비스별로 세밀한 네트워크 경계를 설정할 수 있습니다.

위의 코드를 살펴보겠습니다. 먼저 podSelector에서 정책을 적용할 대상을 지정합니다.

app: api-server 라벨이 붙은 파드에만 이 규칙이 적용됩니다. policyTypes에서는 Ingress와 Egress 모두를 명시했으니, 들어오는 트래픽과 나가는 트래픽 모두 제어 대상이 됩니다.

ingress 섹션에서 실제 허용 규칙을 정의합니다. app: frontend 라벨이 붙은 파드에서 오는 트래픽만 허용한다는 의미입니다.

다른 모든 인바운드 트래픽은 차단됩니다. 실제 현업에서는 어떻게 활용할까요?

3계층 웹 애플리케이션을 예로 들어봅시다. 프론트엔드는 백엔드 API에만, 백엔드는 데이터베이스에만 접근하도록 설정합니다.

이렇게 하면 프론트엔드 파드가 직접 데이터베이스에 접근하는 것을 원천 차단할 수 있습니다. 하지만 주의할 점이 있습니다.

NetworkPolicy를 적용하면 기존에 잘 되던 통신이 갑자기 안 될 수 있습니다. 따라서 먼저 모니터링 모드로 트래픽 패턴을 파악한 후, 단계적으로 정책을 적용하는 것이 좋습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언에 따라 NetworkPolicy를 설정한 후, 더 이상 비정상적인 네트워크 접근은 발생하지 않았습니다.

김개발 씨는 그제야 안도의 한숨을 내쉬었습니다.

실전 팁

💡 - NetworkPolicy는 적용 즉시 효력이 발생하므로, 운영 환경에서는 반드시 테스트 후 배포하세요

• 정책이 없는 파드는 모든 트래픽이 허용되므로, 최소한 기본 거부 정책은 설정해두세요

---

2. Ingress 규칙 설정

김개발 씨는 NetworkPolicy의 기본 개념을 익힌 후, 본격적으로 규칙을 설정하기 시작했습니다. "먼저 누가 우리 서비스에 접근할 수 있는지부터 정의해야겠어요." 바로 Ingress 규칙을 작성할 차례입니다.

Ingress 규칙은 파드로 들어오는 트래픽을 제어합니다. 마치 식당 입구의 웨이터가 예약 손님만 입장시키는 것처럼, 허용된 출발지에서 오는 요청만 받아들입니다.

파드 라벨, 네임스페이스, IP 블록을 기준으로 세밀하게 설정할 수 있습니다.

다음 코드를 살펴봅시다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-ingress-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
    - Ingress
  ingress:
    # 규칙 1: 백엔드 파드에서 3306 포트로만 접근 허용
    - from:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 3306

박시니어 씨가 김개발 씨에게 질문을 던집니다. "데이터베이스 파드에 누가 접근할 수 있어야 할까요?" 김개발 씨는 잠시 생각합니다.

"백엔드 API 서버만 접근해야 합니다. 프론트엔드나 다른 서비스가 직접 DB에 붙으면 안 되죠." 바로 이런 요구사항을 구현하는 것이 Ingress 규칙입니다.

Ingress는 인바운드 트래픽, 즉 파드로 들어오는 연결을 제어합니다. 마치 공항의 입국 심사대처럼, 모든 들어오는 트래픽을 검사하고 허용된 것만 통과시킵니다.

Ingress 규칙을 설정하지 않으면 어떻게 될까요? 클러스터 내의 모든 파드가 해당 서비스에 접근할 수 있습니다.

악의적인 파드가 침투했다면, 데이터베이스의 민감한 정보가 탈취될 수도 있습니다. 위의 코드를 자세히 살펴봅시다.

podSelector에서 app: database 라벨이 붙은 파드를 대상으로 지정했습니다. policyTypes에 Ingress만 명시했으므로, 이 정책은 들어오는 트래픽만 제어합니다.

핵심은 ingress 섹션입니다. from에서 출발지를 app: backend 라벨이 붙은 파드로 한정했습니다.

그리고 ports에서 TCP 3306번 포트만 허용했습니다. MySQL의 기본 포트입니다.

이 설정의 의미를 풀어쓰면 이렇습니다. "backend 라벨이 붙은 파드에서 오는, 3306번 포트 TCP 연결만 허용하고, 나머지는 모두 차단하라." 실무에서 Ingress 규칙은 다양하게 조합할 수 있습니다.

여러 개의 from 조건을 OR로 연결할 수도 있고, 하나의 from 안에 여러 조건을 AND로 묶을 수도 있습니다. 포트 범위를 지정하거나, 여러 포트를 동시에 열 수도 있습니다.

주의할 점이 있습니다. Ingress 정책만 설정하면 Egress는 제어되지 않습니다.

데이터베이스 파드가 외부로 나가는 트래픽은 여전히 자유롭습니다. 완전한 보안을 위해서는 Ingress와 Egress를 함께 설정해야 합니다.

박시니어 씨가 고개를 끄덕입니다. "좋아요.

이제 DB 접근이 백엔드로 제한됐네요. 혹시 모를 내부 위협도 막을 수 있게 됐어요."

실전 팁

💡 - from 조건 없이 ports만 지정하면 모든 출발지에서 해당 포트 접근이 허용됩니다

• 같은 파드에 여러 NetworkPolicy가 적용되면 모든 정책의 허용 규칙이 합쳐집니다

---

3. Egress 규칙 설정

Ingress 규칙을 설정한 김개발 씨에게 박시니어 씨가 또 다른 과제를 던집니다. "이제 우리 파드가 어디로 나갈 수 있는지도 제한해야 해요.

악성코드가 외부 C&C 서버로 데이터를 빼돌리면 어떡해요?" 바로 Egress 규칙이 필요한 순간입니다.

Egress 규칙은 파드에서 나가는 트래픽을 제어합니다. 마치 회사에서 특정 웹사이트만 접속 가능하게 제한하는 것처럼, 파드가 통신할 수 있는 목적지를 명확하게 정의합니다.

데이터 유출 방지와 외부 의존성 관리에 필수적인 설정입니다.

다음 코드를 살펴봅시다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Egress
  egress:
    # 규칙 1: 데이터베이스 파드로 나가는 트래픽 허용
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 3306
    # 규칙 2: DNS 조회를 위한 트래픽 허용 (필수!)
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53

김개발 씨는 Egress 규칙 설정에 착수했습니다. "우리 백엔드 파드는 데이터베이스에만 접속하면 되니까, 그것만 허용하면 되겠네요." 그런데 막상 정책을 적용하니 백엔드 서비스가 완전히 멈춰버렸습니다.

데이터베이스 연결조차 실패했습니다. 무엇이 문제였을까요?

박시니어 씨가 로그를 확인하고 이유를 찾았습니다. "DNS 조회를 빼먹었네요.

파드가 database라는 서비스 이름을 IP로 변환하려면 DNS 서버에 접근해야 해요." 이것이 Egress 규칙 설정의 가장 흔한 실수입니다. 아웃바운드 트래픽을 제한할 때, DNS는 반드시 허용해야 합니다.

그렇지 않으면 서비스 이름을 IP로 해석할 수 없어서 대부분의 통신이 실패합니다. 위의 코드에서 두 번째 egress 규칙을 주목해주세요.

kube-dns 파드로 나가는 UDP 53번 포트 트래픽을 허용합니다. namespaceSelector: {}는 모든 네임스페이스를 의미합니다.

kube-dns는 보통 kube-system 네임스페이스에 있기 때문입니다. Egress 규칙이 왜 중요할까요?

생각해보면, 대부분의 보안 위협은 데이터를 외부로 빼돌리는 것입니다. 랜섬웨어가 파일을 암호화하기 전에 외부 서버로 복사하거나, 악성코드가 탈취한 정보를 C&C 서버로 전송하는 것이죠.

Egress 규칙으로 이런 비정상적인 아웃바운드 트래픽을 원천 차단할 수 있습니다. 실무에서는 외부 API 호출이 필요한 경우도 있습니다.

결제 게이트웨이나 소셜 로그인 같은 외부 서비스 말입니다. 이때는 특정 IP 블록이나 CIDR을 Egress 규칙에 추가해야 합니다.

주의할 점이 또 있습니다. Egress 규칙은 파드 내부에서 localhost로 가는 트래픽에는 적용되지 않습니다.

사이드카 컨테이너와의 통신은 영향을 받지 않습니다. 수정된 정책을 적용하자, 백엔드 서비스가 정상적으로 동작하기 시작했습니다.

김개발 씨는 안도의 한숨을 쉬며 체크리스트에 DNS 허용을 크게 적어두었습니다.

실전 팁

💡 - Egress 정책 설정 시 DNS 허용은 필수입니다 (UDP 53번 포트)

• 외부 서비스 연동 시 해당 IP 대역을 CIDR 형식으로 허용해야 합니다

---

4. 네임스페이스 간 통신 제어

김개발 씨의 회사는 개발, 스테이징, 운영 환경을 각각 다른 네임스페이스로 분리해서 운영하고 있습니다. "네임스페이스만 다르면 안전한 거 아니에요?" 김개발 씨의 순진한 질문에 박시니어 씨가 고개를 젓습니다.

"네임스페이스는 논리적 분리일 뿐, 네트워크 격리는 별도로 설정해야 해요."

네임스페이스 간 통신 제어는 서로 다른 환경이나 팀의 파드들이 무분별하게 통신하는 것을 막습니다. 마치 같은 건물 안에서도 층별로 출입 카드가 달라야 하는 것처럼, 네임스페이스 라벨을 기반으로 교차 통신을 세밀하게 제어할 수 있습니다.

다음 코드를 살펴봅시다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring-namespace
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  policyTypes:
    - Ingress
  ingress:
    # 규칙 1: 같은 네임스페이스의 프론트엔드에서 접근 허용
    - from:
        - podSelector:
            matchLabels:
              app: frontend
    # 규칙 2: monitoring 네임스페이스에서 접근 허용
    - from:
        - namespaceSelector:
            matchLabels:
              name: monitoring
          podSelector:
            matchLabels:
              app: prometheus

박시니어 씨가 화이트보드에 그림을 그리며 설명을 시작합니다. "우리 클러스터에는 production, staging, development, monitoring 네임스페이스가 있어요.

각각 어떤 통신이 필요할까요?" 김개발 씨가 생각해봅니다. "production은 외부 접근만 허용하고, monitoring은 모든 네임스페이스를 수집해야 하니까..." "맞아요.

그게 바로 namespaceSelector가 필요한 이유예요." 기본적으로 podSelector만 사용하면 같은 네임스페이스 안에서만 파드를 선택합니다. 다른 네임스페이스의 파드를 선택하려면 반드시 namespaceSelector를 함께 사용해야 합니다.

위의 코드에서 두 가지 규칙을 비교해보세요. 첫 번째 규칙은 podSelector만 있습니다.

이 경우 같은 네임스페이스(production)에서 app: frontend 라벨이 붙은 파드만 선택됩니다. 두 번째 규칙에는 namespaceSelector와 podSelector가 함께 있습니다.

이것은 AND 조건입니다. name: monitoring 라벨이 붙은 네임스페이스에서, app: prometheus 라벨이 붙은 파드만 선택됩니다.

여기서 중요한 점이 있습니다. 네임스페이스에 라벨을 붙여야 namespaceSelector로 선택할 수 있습니다.

기본적으로 네임스페이스에는 라벨이 없으므로, 다음 명령어로 라벨을 추가해야 합니다. 실무에서 흔히 사용하는 패턴이 있습니다.

모니터링 시스템은 모든 네임스페이스에 접근해야 하고, CI/CD 파이프라인은 staging과 production 양쪽에 배포해야 합니다. 이런 교차 네임스페이스 통신은 명시적으로 허용해야 합니다.

만약 namespaceSelector와 podSelector를 별도의 배열 요소로 분리하면 어떻게 될까요? 그러면 OR 조건이 됩니다.

모든 네임스페이스 또는 특정 파드가 접근 가능해지므로, 의도치 않게 보안이 느슨해질 수 있습니다. 항상 두 조건을 같은 from 항목 안에 넣어서 AND 조건으로 만들어야 합니다.

김개발 씨가 고개를 끄덕입니다. "그래서 개발 환경 파드가 운영 DB에 접근했던 거군요.

네임스페이스 라벨 기반으로 차단해야겠네요."

실전 팁

💡 - 네임스페이스에 라벨을 붙이는 것을 잊지 마세요: kubectl label namespace monitoring name=monitoring

• namespaceSelector와 podSelector를 같은 from 안에 넣으면 AND, 별도 from으로 분리하면 OR 조건입니다

---

5. 기본 거부 정책

김개발 씨가 NetworkPolicy를 하나씩 적용하던 중, 박시니어 씨가 중요한 질문을 던집니다. "지금 정책이 없는 파드는 어떻게 되고 있을까요?" 김개발 씨가 확인해보니, 정책 없는 파드들은 여전히 모든 통신이 열려 있었습니다.

"기본값이 허용이라니... 위험하네요!"

기본 거부 정책은 명시적으로 허용하지 않은 모든 트래픽을 차단하는 제로 트러스트 접근법입니다. 마치 화이트리스트 기반 방화벽처럼, 허용 목록에 없는 모든 연결을 거부합니다.

네임스페이스 전체에 적용하여 보안의 기본 수준을 높일 수 있습니다.

다음 코드를 살펴봅시다.

# 기본 거부 정책: 모든 인바운드 트래픽 차단
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  # 빈 podSelector는 네임스페이스의 모든 파드 선택
  podSelector: {}
  policyTypes:
    - Ingress
---
# 기본 거부 정책: 모든 아웃바운드 트래픽 차단
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress

쿠버네티스의 기본 네트워크 동작은 모든 것을 허용하는 것입니다. NetworkPolicy가 하나도 없으면, 클러스터 내의 모든 파드는 서로 자유롭게 통신할 수 있습니다.

박시니어 씨가 설명합니다. "이건 마치 모든 문이 열려 있는 집과 같아요.

편리하긴 하지만, 보안에는 치명적이죠." 기본 거부 정책은 이 상황을 반전시킵니다. 먼저 모든 문을 잠그고, 그 다음에 필요한 문만 열어주는 방식입니다.

위의 코드를 살펴봅시다. 핵심은 **podSelector: {}**입니다.

빈 셀렉터는 해당 네임스페이스의 모든 파드를 선택한다는 의미입니다. 그리고 ingress나 egress 규칙을 정의하지 않았습니다.

규칙이 없다는 것은 아무것도 허용하지 않는다는 뜻입니다. 결과적으로, 이 정책이 적용되면 production 네임스페이스의 모든 파드는 인바운드 트래픽을 받을 수 없고, 아웃바운드 트래픽을 보낼 수도 없습니다.

완전히 격리된 상태가 됩니다. 물론 이대로 두면 서비스가 동작하지 않습니다.

기본 거부 정책을 적용한 후에는, 필요한 통신을 허용하는 추가 정책을 반드시 설정해야 합니다. 앞서 배운 Ingress와 Egress 규칙들이 바로 그것입니다.

실무에서 권장하는 순서는 이렇습니다. 먼저 기본 거부 정책을 적용합니다.

그 다음, 각 서비스에 필요한 통신을 분석합니다. 마지막으로 필요한 연결만 명시적으로 허용하는 정책을 추가합니다.

주의할 점이 있습니다. 기본 거부 정책을 갑자기 적용하면 서비스 장애가 발생합니다.

반드시 충분한 테스트를 거친 후, 먼저 허용 정책을 준비해두고 기본 거부 정책을 적용해야 합니다. 김개발 씨가 체크리스트를 만들기 시작합니다.

"DNS 허용, 백엔드-DB 연결 허용, 프론트엔드-백엔드 연결 허용... 이것들을 먼저 만들어두고 기본 거부를 적용하면 되겠네요!"

실전 팁

💡 - 기본 거부 정책을 적용하기 전에 반드시 필요한 허용 정책을 먼저 준비하세요

• 새 네임스페이스를 생성할 때마다 기본 거부 정책을 자동으로 적용하는 것이 좋습니다

---

6. CNI 플러그인과 NetworkPolicy

모든 정책을 완벽하게 설정한 김개발 씨는 의기양양하게 kubectl apply를 실행했습니다. 그런데 이상합니다.

정책은 생성됐는데, 차단되어야 할 트래픽이 그대로 통과하고 있었습니다. "왜 정책이 안 먹히는 거죠?" 박시니어 씨가 한숨을 쉬며 말합니다.

"혹시 우리 클러스터 CNI가 뭔지 확인해봤어요?"

CNI 플러그인은 쿠버네티스의 네트워크를 실제로 구현하는 컴포넌트입니다. 중요한 점은, 모든 CNI가 NetworkPolicy를 지원하는 것은 아니라는 것입니다.

마치 법률이 있어도 경찰이 없으면 집행할 수 없는 것처럼, NetworkPolicy를 실제로 적용하려면 이를 지원하는 CNI가 필요합니다.

다음 코드를 살펴봅시다.

# CNI 확인: kube-system 네임스페이스의 파드 확인
kubectl get pods -n kube-system

# 대표적인 NetworkPolicy 지원 CNI 파드 이름:
# - calico-node-xxxxx (Calico)
# - cilium-xxxxx (Cilium)
# - weave-net-xxxxx (Weave Net)

# NetworkPolicy 지원하지 않는 CNI:
# - kindnet (kind 기본 CNI)
# - flannel (기본 설정)

# Calico 설치 예시 (NetworkPolicy 지원)
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

# 정책 적용 확인
kubectl describe networkpolicy default-deny-ingress -n production

김개발 씨는 당황했습니다. 분명히 kubectl get networkpolicy 명령어로 확인하면 정책이 잘 생성되어 있는데, 왜 트래픽이 차단되지 않는 걸까요?

박시니어 씨가 차근차근 설명합니다. "쿠버네티스 API는 NetworkPolicy 리소스를 저장하기만 해요.

실제로 이 정책을 네트워크에 적용하는 건 CNI 플러그인의 역할이에요." CNI는 Container Network Interface의 약자입니다. 파드 간 네트워크를 구성하고, IP를 할당하고, 라우팅을 설정하는 모든 것을 CNI가 담당합니다.

그리고 NetworkPolicy의 적용도 CNI의 몫입니다. 문제는 모든 CNI가 NetworkPolicy를 지원하지 않는다는 것입니다.

대표적으로 Flannel의 기본 설정은 NetworkPolicy를 지원하지 않습니다. 정책을 아무리 만들어도 무시됩니다.

kindnet도 마찬가지입니다. 로컬 개발 환경에서 kind를 사용한다면, 기본 CNI로는 NetworkPolicy를 테스트할 수 없습니다.

NetworkPolicy를 지원하는 대표적인 CNI는 Calico, Cilium, Weave Net 등이 있습니다. 이 중에서 Calico가 가장 널리 사용됩니다.

설치도 간단하고, NetworkPolicy 외에도 다양한 보안 기능을 제공합니다. 김개발 씨가 클러스터를 확인해보니, Flannel이 설치되어 있었습니다.

"그래서 정책이 안 먹힌 거군요..." 박시니어 씨가 조언합니다. "Calico로 마이그레이션하거나, 최소한 Flannel과 Calico를 함께 사용하는 방법도 있어요.

Canal이라고 부르는 조합이에요." CNI를 변경하는 것은 큰 작업입니다. 운영 중인 클러스터에서는 신중하게 접근해야 합니다.

하지만 보안이 중요한 환경이라면, NetworkPolicy 지원은 필수입니다. 클러스터를 새로 구축할 때부터 적절한 CNI를 선택하는 것이 좋습니다.

Cilium은 최근 각광받는 CNI입니다. eBPF 기술을 활용하여 더 세밀하고 효율적인 네트워크 정책을 제공합니다.

L7 정책도 지원해서 HTTP 경로나 헤더 기반으로도 트래픽을 제어할 수 있습니다. 김개발 씨가 결론을 내립니다.

"앞으로 클러스터 구축할 때는 반드시 CNI부터 확인해야겠어요. NetworkPolicy 지원 여부가 보안의 시작이네요."

실전 팁

💡 - 클러스터 구축 시 NetworkPolicy 지원 CNI를 선택하세요: Calico, Cilium, Weave Net 등

• 기존 클러스터의 CNI를 확인하려면: kubectl get pods -n kube-system 명령어로 CNI 파드를 찾으세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!