Kubernetes 네트워크 정책으로 Pod 트래픽 제한하기

Kubernetes 네트워크 정책으로 Pod 트래픽 제한하기 (Limit Pod traffic with Kubernetes network policies)

개요 (Overview)

기본적으로 Kubernetes는 클러스터의 모든 Pod 사이 또는 Pod와 다른 네트워크의 리소스 사이에 IP 주소, 포트, 연결에 대한 제한이 없어요. Kubernetes 네트워크 정책을 사용해 Pod와의 네트워크 트래픽을 제한할 수 있어요. 자세한 내용은 Kubernetes 문서의 Network Policies를 참고하세요.

출처: 문서

본문

표준 네트워크 정책 (Standard network policy)

표준 NetworkPolicy를 사용해 클러스터의 Pod 간 트래픽을 세그먼트화할 수 있어요. 이러한 네트워크 정책은 OSI 네트워크 모델의 레이어 3과 4에서 작동하며, Amazon EKS 클러스터 내에서 IP 주소 또는 포트 수준으로 트래픽 흐름을 제어할 수 있게 해줘요. 표준 네트워크 정책은 네임스페이스 수준으로 범위가 지정돼요.

사용 사례

  • 관련된 애플리케이션끼리만 통신할 수 있도록 워크로드 간 네트워크 트래픽을 세그먼트화해요.
  • 정책을 사용해 네임스페이스 수준에서 테넌트를 격리해 네트워크 분리를 강제해요.

예시

아래 정책에서 sun 네임스페이스의 webapp Pod에서 나가는 이그레스 트래픽이 제한돼요.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: webapp-egress-policy
  namespace: sun
spec:
  podSelector:
    matchLabels:
      role: webapp
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: moon
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080
  - to:
    - namespaceSelector:
        matchLabels:
          name: stars
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

정책은 sun 네임스페이스에서 role: webapp 레이블이 있는 Pod에 적용돼요.

  • 허용된 트래픽: moon 네임스페이스에서 TCP 포트 8080의 role: frontend 레이블이 있는 Pod.
  • 허용된 트래픽: stars 네임스페이스에서 TCP 포트 8080의 role: frontend 레이블이 있는 Pod.
  • 차단된 트래픽: webapp Pod에서 나가는 다른 모든 아웃바운드 트래픽은 암시적으로 거부돼요.

관리자(또는 클러스터) 네트워크 정책 (Admin (or cluster) network policy)

ClusterNetworkPolicy를 사용해 전체 클러스터에 적용되는 네트워크 보안 표준을 강제할 수 있어요. 각 네임스페이스에 대해 별도의 정책을 반복적으로 정의하고 유지관리하는 대신, 단일 정책으로 네임스페이스와 관계없이 클러스터의 다양한 워크로드에 대한 네트워크 접근 제어를 중앙에서 관리할 수 있어요.

사용 사례

  • EKS 클러스터의 모든(또는 일부) 워크로드에 대한 네트워크 접근 제어를 중앙에서 관리해요.
  • 클러스터 전반에 걸쳐 기본 네트워크 보안 태세를 정의해요.
  • 조직 보안 표준을 클러스터 범위로 더 운영 효율적으로 확장해요.

예시

아래 정책에서 다른 네임스페이스의 클러스터 트래픽을 명시적으로 차단해 민감한 워크로드 네임스페이스에 대한 네트워크 접근을 방지할 수 있어요.

apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: protect-sensitive-workload
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: earth
  ingress:
    - action: Deny
      from:
      - namespaces:
          matchLabels: {} # Match all namespaces.
      name: select-all-deny-all

중요 참고 사항 (Important notes)

Kubernetes용 Amazon VPC CNI 플러그인의 네트워크 정책은 아래 나열된 구성에서 지원돼요.

  • 표준 및 관리자 네트워크 정책 모두에 대해 Amazon VPC CNI 플러그인 버전 1.21.0(또는 이후).
  • IPv4 또는 IPv6 주소로 구성된 클러스터.
  • Pod용 보안 그룹과 함께 네트워크 정책을 사용할 수 있어요. 네트워크 정책으로 모든 인클러스터 통신을 제어하고, Pod용 보안 그룹으로 Pod 내 애플리케이션에서 AWS 서비스에 대한 접근을 제어할 수 있어요.
  • 커스텀 네트워킹 및 접두사 위임(prefix delegation)과 함께 네트워크 정책을 사용할 수 있어요.

고려 사항 (Considerations)

아키텍처

Kubernetes용 Amazon VPC CNI 플러그인 네트워크 정책을 클러스터에 적용할 때는 Amazon EC2 Linux 노드에만 적용할 수 있어요. Fargate 또는 Windows 노드에는 적용할 수 없어요.

네트워크 정책은 IPv4 또는 IPv6 주소 중 하나에만 적용되며 둘 다에는 적용되지 않아요. IPv4 클러스터에서 VPC CNI는 Pod에 IPv4 주소를 할당하고 IPv4 정책을 적용해요. IPv6 클러스터에서 VPC CNI는 Pod에 IPv6 주소를 할당하고 IPv6 정책을 적용해요. IPv6 클러스터에 적용된 IPv4 네트워크 정책 규칙은 무시돼요. IPv4 클러스터에 적용된 IPv6 네트워크 정책 규칙은 무시돼요.

네트워크 정책

  • Amazon EKS는 metadata.ownerReferences 필드가 설정된 Pod에 대한 네트워크 정책 적용을 최적화해요. 여기에는 Deployment, StatefulSet, DaemonSet, Job, CronJob 같은 컨트롤러가 관리하는 Pod가 포함돼요. 컨트롤러 없이 직접 만든 독립형 Pod는 metadata.ownerReferences가 설정되지 않으며, 이러한 Pod에는 네트워크 정책 적용이 안정적으로 작동하지 않을 수 있어요.
  • 같은 Pod에 여러 네트워크 정책을 적용할 수 있어요. 같은 Pod를 선택하는 정책이 둘 이상 구성되면 모든 정책이 Pod에 적용돼요.
  • 단일 IP 주소 범위(CIDR)에 대한 포트와 프로토콜 조합의 최대 수는 모든 네트워크 정책에서 24개예요. namespaceSelector 같은 선택기는 하나 이상의 CIDR로 해석돼요. 여러 선택기가 단일 CIDR로 해석되거나 같은 네트워크 정책이나 다른 네트워크 정책에서 동일한 직접 CIDR을 여러 번 지정한다면 이 모두가 이 제한에 포함돼요.
  • Kubernetes 서비스의 경우 서비스 포트는 컨테이너 포트와 같아야 해요. 명명된 포트를 사용한다면 서비스 spec에서도 같은 이름을 사용하세요.

관리자 네트워크 정책

  • Admin 티어 정책(먼저 평가됨): 모든 Admin 티어 ClusterNetworkPolicy는 다른 정책보다 먼저 평가돼요. Admin 티어 내에서 정책은 우선순위 순서(가장 낮은 우선순위 번호부터)로 처리돼요. 작업 유형이 다음에 일어날 일을 결정해요.
    • Deny 작업(최고 우선순위): Deny 작업이 있는 Admin 정책이 트래픽과 일치하면 다른 정책과 관계없이 해당 트래픽은 즉시 차단돼요. 더 이상의 ClusterNetworkPolicy 또는 NetworkPolicy 규칙은 처리되지 않아요. 이는 조직 차원의 보안 제어가 네임스페이스 수준 정책으로 재정의될 수 없도록 보장해요.
    • Allow 작업: Deny 규칙이 평가된 후 Allow 작업이 있는 Admin 정책이 우선순위 순서(가장 낮은 우선순위 번호부터)로 처리돼요. Allow 작업이 일치하면 트래픽이 허용되고 더 이상의 정책 평가는 발생하지 않아요. 이러한 정책은 레이블 선택기를 기반으로 여러 네임스페이스에 걸쳐 접근을 부여할 수 있어, 특정 워크로드가 특정 리소스에 접근할 수 있는지에 대한 중앙 집중식 제어를 제공해요.
    • Pass 작업: Admin 티어 정책의 Pass 작업은 결정을 하위 티어에 위임해요. 트래픽이 Pass 규칙과 일치하면 해당 트래픽에 대한 나머지 Admin 티어 규칙을 모두 건너뛰고 NetworkPolicy 티어로 직접 진행해요. 이를 통해 관리자가 특정 트래픽 패턴에 대한 제어를 애플리케이션 팀에 명시적으로 위임할 수 있어요. 예를 들어 외부 접근에 대한 엄격한 제어를 유지하면서 네임스페이스 내 트래픽 관리를 네임스페이스 관리자에게 위임하는 데 Pass 규칙을 사용할 수 있어요.
  • 네트워크 정책 티어: Admin 티어 정책이 Deny 또는 Allow로 일치하지 않거나 Pass 작업이 일치했다면, 다음으로 네임스페이스 범위의 NetworkPolicy 리소스가 평가돼요. 이러한 정책은 개별 네임스페이스 내에서 세분화된 제어를 제공하며 애플리케이션 팀이 관리해요. 네임스페이스 범위 정책은 Admin 정책보다 더 제한적일 수만 있어요. Admin 정책의 Deny 결정을 재정의할 수는 없지만, Admin 정책이 허용하거나 통과시킨 트래픽을 더 제한할 수는 있어요.
  • Baseline 티어 Admin 정책: Admin 또는 네임스페이스 범위 정책이 트래픽과 일치하지 않으면 Baseline 티어 ClusterNetworkPolicy가 평가돼요. 이는 네임스페이스 범위 정책으로 재정의될 수 있는 기본 보안 태세를 제공해, 관리자가 조직 차원의 기본값을 설정하면서 팀이 필요에 따라 커스터마이징할 수 있는 유연성을 제공해요. Baseline 정책은 우선순위 순서(가장 낮은 우선순위 번호부터)로 평가돼요.
  • 기본 거부(일치하는 정책이 없는 경우): 이 기본 거부(deny-by-default) 동작은 명시적으로 허용된 연결만 허용되도록 보장하며 강력한 보안 태세를 유지해요.

마이그레이션

클러스터가 현재 타사 솔루션으로 Kubernetes 네트워크 정책을 관리하고 있다면, 동일한 정책을 Kubernetes용 Amazon VPC CNI 플러그인과 함께 사용할 수 있어요. 하지만 기존 솔루션을 제거해 같은 정책을 관리하지 않도록 해야 해요.

경고

네트워크 정책 솔루션을 제거한 후에는 정책 솔루션이 적용되었던 모든 노드를 교체하는 것을 권장해요. 솔루션의 Pod가 갑자기 종료되면 트래픽 규칙이 남겨질 수 있기 때문이에요.

설치

네트워크 정책 기능은 policyendpoints.networking.k8s.aws라는 PolicyEndpoint 커스텀 리소스 정의(CRD)를 만들고 요구해요. 이 커스텀 리소스의 PolicyEndpoint 객체는 Amazon EKS가 관리해요. 이러한 리소스를 수정하거나 삭제해서는 안 돼요.

인스턴스 역할 IAM 자격 증명을 사용하거나 EC2 IMDS에 연결하는 Pod를 실행한다면 EC2 IMDS에 대한 접근을 차단하는 네트워크 정책이 있는지 주의해서 확인하세요. EC2 IMDS에 대한 접근을 허용하는 네트워크 정책을 추가해야 할 수도 있어요. 자세한 내용은 Amazon EC2 사용 설명서의 인스턴스 메타데이터 및 사용자 데이터를 참고하세요.

서비스 계정용 IAM 역할 또는 EKS Pod Identity를 사용하는 Pod는 EC2 IMDS에 접근하지 않아요.

Kubernetes용 Amazon VPC CNI 플러그인은 각 Pod의 추가 네트워크 인터페이스에는 네트워크 정책을 적용하지 않고 각 Pod의 기본 인터페이스(eth0)에만 적용해요. 이는 다음 아키텍처에 영향을 줘요.

  • ENABLE_V4_EGRESS 변수가 true로 설정된 IPv6 Pod. 이 변수는 IPv6 Pod를 클러스터 밖의 IPv4 엔드포인트 같은 곳에 연결하는 IPv4 이그레스 기능을 활성화해요. IPv4 이그레스 기능은 로컬 루프백 IPv4 주소가 있는 추가 네트워크 인터페이스를 만들어 작동해요.
  • Multus 같은 체이닝 네트워크 플러그인 사용 시. 이러한 플러그인은 각 Pod에 네트워크 인터페이스를 추가하므로 네트워크 정책이 체이닝 네트워크 플러그인에는 적용되지 않아요.

더 알아보기 (Learn more)