EKS Auto Mode에서 Network Policies 사용하기

개요

고객이 EKS로 애플리케이션 환경을 확장함에 따라, 클러스터 안팎의 리소스에 대한 무단 접근을 방지하는 네트워크 트래픽 격리가 점점 더 근본적으로 중요해집니다. 이는 서로 관련 없는 여러 워크로드가 클러스터에서 나란히 실행되는 다중 테넌트 환경에서 특히 중요합니다. Kubernetes 네트워크 정책을 사용하면 Kubernetes 워크로드와 클러스터 외부 엔드포인트와의 통합에 대한 네트워크 보안 태세를 강화할 수 있어요. EKS Auto Mode는 다양한 유형의 네트워크 정책을 지원합니다.

레이어 3 및 4 격리

표준 Kubernetes 네트워크 정책은 OSI 네트워크 모델의 레이어 3과 4에서 작동하며, Amazon EKS 클러스터 내 IP 주소 또는 포트 수준에서 트래픽 흐름을 제어할 수 있게 합니다.

사용 사례:

워크로드 간 네트워크 트래픽을 분리해 관련 애플리케이션만 서로 통신하도록 보장합니다.
네임스페이스 수준에서 정책을 사용해 테넌트를 격리하고 네트워크 분리를 적용합니다.

DNS 기반 시행

고객은 보통 더 넓은 분산 환경의 일부인 워크로드를 EKS에 배포하며, 그중 일부는 클러스터 외부의 시스템·서비스와 통신해야 합니다(북바운드 트래픽). 이러한 시스템·서비스는 AWS 클라우드에 있거나 AWS 밖에 있을 수 있어요. Domain Name System(DNS) 기반 정책을 사용하면 Pod에서 클러스터 외부 리소스·엔드포인트로의 무단 접근을 방지하는 더 안정적이고 예측 가능한 접근 방식을 채택해 보안 태세를 강화할 수 있습니다. 이 메커니즘은 특정 IP 주소를 수동으로 추적·허용 목록에 추가할 필요를 없앱니다. DNS 기반 접근 방식으로 리소스를 보호하면 업스트림 서버·호스트가 변경될 때 보안 태세를 완화하거나 네트워크 정책을 수정하지 않고도 외부 인프라를 업데이트하는 더 큰 유연성을 얻을 수 있어요. 정규화된 도메인 이름(FQDN) 또는 DNS 도메인 이름의 일치 패턴을 사용해 외부 엔드포인트로의 이그레스 트래픽을 필터링할 수 있습니다. 이를 통해 특정 클러스터 외부 엔드포인트와 연관된 여러 하위 도메인으로 접근을 확장하는 추가 유연성을 얻을 수 있어요.

사용 사례:

Kubernetes 환경에서 클러스터 외부 엔드포인트로의 접근을 필터링하는 DNS 기반 접근 방식을 표준화합니다.
다중 테넌트 환경에서 AWS 서비스에 대한 접근을 보호합니다.
하이브리드 클라우드 환경에서 Pod에서 온프레미스 워크로드로의 네트워크 접근을 관리합니다.

Admin(또는 클러스터 범위) 규칙

다중 테넌트 시나리오처럼 클러스터 전체에 적용되는 네트워크 보안 표준을 시행해야 하는 요구가 있을 수 있습니다. 네임스페이스별로 개별 정책을 반복적으로 정의·유지하는 대신, 네임스페이스와 무관하게 클러스터의 다른 워크로드에 대한 네트워크 접근 제어를 중앙에서 관리하는 단일 정책을 사용할 수 있어요. 이러한 유형의 정책은 레이어 3, 레이어 4 및 DNS 규칙 사용 시 적용되는 네트워크 필터링 규칙의 시행 범위를 확장할 수 있게 합니다.

사용 사례:

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

출처: 문서

본문

시작하기

사전 조건

EKS Auto Mode가 활성화된 Amazon EKS 클러스터
클러스터에 연결하도록 구성된 kubectl

1단계: Network Policy Controller 활성화

EKS Auto Mode에서 네트워크 정책을 사용하려면 먼저 ConfigMap을 클러스터에 적용해 Network Policy Controller를 활성화해야 합니다.

enable-network-policy.yaml 파일을 다음 내용으로 만듭니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-network-policy-controller: "true"

ConfigMap을 클러스터에 적용합니다.

kubectl apply -f enable-network-policy.yaml

2단계: 네트워크 정책 생성 및 테스트

이제 EKS Auto Mode 클러스터가 Kubernetes 네트워크 정책을 지원하도록 구성되었습니다. Amazon EKS용 네트워크 정책의 Stars 데모로 테스트할 수 있어요.

3단계: Node Class에서 Network Policy Agent 구성 조정(선택)

노드의 Network Policy Agent 기본 동작을 변경하거나 Network Policy 이벤트 로깅을 활성화하기 위해 선택적으로 새 Node Class를 만들 수 있어요. 다음 단계를 따르세요.

다음 내용으로 Node Class YAML 파일(예: nodeclass-network-policy.yaml)을 만들거나 편집합니다.

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: network-policy-config
spec:
  # Optional: Changes default network policy behavior
  networkPolicy: DefaultAllow
  # Optional: Enables logging for network policy events
  networkPolicyEventLogs: Enabled
  # Include other Node Class configurations as needed

Node Class 구성을 클러스터에 적용합니다.

kubectl apply -f nodeclass-network-policy.yaml

Node Class가 생성되었는지 확인합니다.

kubectl get nodeclass network-policy-config

이 Node Class를 사용하도록 Node Pool을 업데이트합니다. 자세한 내용은 Create a Node Pool for EKS Auto Mode를 참고하세요.

작동 방식

DNS 기반 네트워크 정책

플랫폼 팀이 EKS 클러스터에 DNS 기반 정책을 적용합니다.
Network Policy Controller는 클러스터 내 정책 생성을 모니터링하고 정책 엔드포인트를 조정(reconcile)합니다. 이 사용 사례에서 네트워크 정책 컨트롤러는 생성된 정책의 허용 목록 도메인을 기준으로 DNS 요청을 필터링하도록 노드 에이전트에 지시합니다. 도메인 이름은 Kubernetes 리소스 구성에 정의된 FQDN 또는 패턴과 일치하는 도메인 이름으로 허용 목록에 추가됩니다.
Workload A가 클러스터 외부 엔드포인트의 IP를 해석하려고 시도합니다. DNS 요청은 먼저 네트워크 정책을 통해 적용된 허용 목록을 기준으로 그러한 요청을 필터링하는 프록시를 통과합니다.
DNS 요청이 DNS 필터 허용 목록을 통과한 후 프록시는 이를 CoreDNS로 전달합니다.
CoreDNS는 요청을 External DNS Resolver(Amazon Route 53 Resolver)로 보내 도메인 이름 뒤의 IP 주소 목록을 가져옵니다.
TTL이 있는 해석된 IP가 DNS 요청에 대한 응답으로 반환됩니다. 이 IP는 다음 단계에서 IP 레이어 시행에 사용되는 eBPF 맵에 기록됩니다.
Pod veth 인터페이스에 연결된 eBPF 프로브는 규칙에 따라 Workload A에서 클러스터 외부 엔드포인트로의 이그레스 트래픽을 필터링합니다. 이는 Pod가 허용 목록 도메인의 IP로만 클러스터 외부 트래픽을 보낼 수 있도록 보장합니다. 이 IP의 유효성은 External DNS Resolver(Amazon Route 53 Resolver)에서 가져온 TTL에 기반합니다.

Application Network Policy 사용

ApplicationNetworkPolicy는 단일 Custom Resource Definition(CRD)으로 네임스페이스 수준에서 표준 Kubernetes 네트워크 정책의 기능과 DNS 기반 필터링을 결합합니다. 따라서 ApplicationNetworkPolicy는 다음에 사용될 수 있어요.

IP 블록과 포트 번호를 사용해 네트워크 스택의 레이어 3과 4에서 제한을 정의합니다.
네트워크 스택의 레이어 7에서 작동하며 FQDN을 기준으로 트래픽을 필터링할 수 있는 규칙을 정의합니다.

Important: ApplicationNetworkPolicy로 정의된 DNS 기반 규칙은 EKS Auto Mode가 시작한 EC2 인스턴스에서 실행되는 워크로드에만 적용됩니다. ApplicationNetworkPolicy는 표준 Kubernetes NetworkPolicy의 모든 필드를 지원하며, 이그레스 규칙에 대한 추가 FQDN 필터가 있습니다.

Warning: 같은 네임스페이스 안에서 ApplicationNetworkPolicy와 NetworkPolicy에 같은 이름을 사용하지 마세요. 이름이 충돌하면 결과 PolicyEndpoints 객체가 두 정책 중 하나도 제대로 반영하지 못할 수 있습니다. 두 리소스 모두 오류 없이 수락되어 문제 진단이 어렵습니다. 이름 충돌을 해결하려면 ApplicationNetworkPolicy 또는 NetworkPolicy 중 하나의 이름을 바꿔 네임스페이스 내에서 고유하게 만든 다음 해당 PolicyEndpoints 객체가 올바르게 업데이트되었는지 확인하세요.

예시: EKS Auto Mode 클러스터에 DNS 이름이 있는 로드 밸런서 뒤의 온프레미스 애플리케이션과 통신해야 하는 워크로드가 있습니다. 다음 네트워크 정책으로 이를 달성할 수 있어요.

apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
  name: my-onprem-app-egress
  namespace: galaxy
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock: { cidr: 10.100.0.10/32 }
    ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53
  - to:
    - domainNames:
      - "myapp.mydomain.com"
    ports:
    - protocol: TCP
      port: 8080

Kubernetes 네트워크 수준에서 이는 "galaxy" 네임스페이스에서 role: backend 라벨이 붙은 모든 Pod의 이그레스가 myapp.mydomain.com 도메인 이름의 TCP 포트 8080과 CoreDNS의 포트 53에 연결되도록 허용합니다. 또한 VPC에서 회사 데이터 센터로의 이그레스 트래픽용 네트워크 연결을 설정해야 합니다.

CoreDNS IP 주소 결정

애플리케이션이 DNS를 해석하려면 각 EKS Auto Mode 인스턴스에서 로컬로 실행되는 CoreDNS와 통신할 수 있어야 합니다. CoreDNS IP 주소는 클러스터에 구성된 Service CIDR 범위에서 파생되며 클러스터 수명 내내 고정적으로 유지됩니다. 따라서 한 번 결정해 네트워크 정책에서 직접 참조할 수 있어요.

클러스터의 Service CIDR을 가져옵니다.

IPv4 클러스터의 경우:

aws eks describe-cluster --name my-cluster --query 'cluster.kubernetesNetworkConfig.serviceIpv4Cidr' --output text

IPv6 클러스터의 경우:

aws eks describe-cluster --name my-cluster --query 'cluster.kubernetesNetworkConfig.serviceIpv6Cidr' --output text

Service CIDR에서 CoreDNS IP 주소를 파생합니다.

IPv4 — CIDR의 .10 주소를 사용합니다. 예: 10.100.0.0/16은 10.100.0.10/32가 됩니다.
IPv6 — 네트워크 주소에 a를 추가합니다. 예: fd12:3456:789a::/108은 fd12:3456:789a::a/128이 됩니다.

Cluster Network Policy 사용

ClusterNetworkPolicy를 사용할 때 Admin 티어 정책이 먼저 평가되며 재정의될 수 없습니다. Admin 티어 정책이 평가된 후, 표준 네임스페이스 범위 정책을 사용해 적용된 네트워크 분할 규칙을 실행합니다. 이는 ApplicationNetworkPolicy 또는 NetworkPolicy를 사용해 수행할 수 있어요. 마지막으로 클러스터 워크로드의 기본 네트워크 제한을 정의하는 Baseline 티어 규칙이 시행됩니다. 이 Baseline 티어 규칙은 필요 시 네임스페이스 범위 정책으로 재정의할 수 있습니다.

예시: 클러스터에 다른 테넌트 워크로드로부터 격리하려는 애플리케이션이 있습니다. 민감한 워크로드 네임스페이스에 대한 네트워크 접근을 방지하기 위해 다른 네임스페이스의 클러스터 트래픽을 명시적으로 차단할 수 있어요.

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

고려 사항

정책 평가 순서 이해

EKS에서 지원되는 네트워크 정책 기능은 예측 가능하고 안전한 트래픽 관리를 보장하기 위해 특정 순서로 평가됩니다. 따라서 환경에 효과적인 네트워크 보안 태세를 설계하려면 평가 흐름을 이해하는 것이 중요합니다.

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

최소 권한 원칙 적용

제한적인 정책으로 시작하고 필요에 따라 권한을 점진적으로 추가합니다 — 먼저 클러스터 수준에서 deny-by-default 정책을 구현한 다음, 합법적인 연결 요구사항을 검증하면서 allow 규칙을 점진적으로 추가하세요. 이 접근 방식은 각 외부 연결을 팀이 명시적으로 정당화하게 하여 더 안전하고 감사 가능한 환경을 만듭니다.
정기적으로 감사하고 사용하지 않는 정책 규칙을 제거합니다 — 애플리케이션이 진화함에 따라 네트워크 정책이 축적되어 불필요하게 공격 표면을 넓히는 구식 규칙이 남을 수 있습니다. 더 이상 필요 없는 정책 규칙을 식별·제거하는 정기 검토 프로세스를 구현해 보안 태세를 견고하고 유지 관리 가능하게 유지하세요.
가능하면 광범위한 패턴보다 특정 도메인 이름을 사용합니다 — *.amazonaws.com 같은 와일드카드 패턴은 편리함을 제공하지만 광범위한 서비스에 대한 접근도 부여합니다. 가능할 때마다 s3.us-west-2.amazonaws.com 같은 정확한 도메인 이름을 지정해 애플리케이션이 필요로 하는 특정 서비스에만 접근을 제한하여, 워크로드가 손상되어도 측면 이동의 위험을 줄입니다.

EKS에서 DNS 기반 정책 사용

ApplicationNetworkPolicy로 정의된 DNS 기반 규칙은 EKS Auto Mode가 시작한 EC2 인스턴스에서 실행되는 워크로드에만 적용됩니다. 혼합 모드 클러스터(EKS Auto와 비 EKS Auto 워커 노드 모두로 구성)를 실행한다면 DNS 기반 규칙은 EKS Auto 모드 워커 노드(EC2 관리형 인스턴스)에서만 효과적입니다.

DNS 정책 검증

테스트용으로 프로덕션 네트워크 토폴로지를 미러링하는 스테이징 클러스터를 사용합니다 — 스테이징 환경은 정확한 정책 테스트를 보장하기 위해 프로덕션의 네트워크 아키텍처, 외부 종속성, 연결 패턴을 재현해야 합니다. 여기에는 VPC 구성 일치, DNS 해석 동작, 프로덕션 워크로드가 요구하는 동일한 외부 서비스 접근이 포함됩니다.
크리티컬 네트워크 경로에 대한 자동화된 테스트를 구현합니다 — CI/CD 파이프라인의 일부로 필수 외부 서비스에 대한 연결성을 검증하는 자동화 테스트를 구축하세요. 이 테스트는 합법적인 트래픽 흐름이 허용되고 무단 연결이 차단되는지 확인하여, 인프라가 진화함에 따라 네트워크 정책이 올바른 보안 태세를 유지하는지 지속적으로 검증합니다.
정책 변경 후 애플리케이션 동작을 모니터링합니다 — 새로 배포하거나 수정한 네트워크 정책을 프로덕션에 적용한 후 애플리케이션 로그, 오류율, 성능 메트릭을 면밀히 모니터링해 연결 문제를 신속히 식별하세요. 정책 변경이 예기치 않은 애플리케이션 동작이나 서비스 중단을 일으키면 빠르게 되돌릴 수 있도록 명확한 롤백 절차를 수립합니다.

Amazon Route 53 DNS firewall과의 상호작용

EKS Admin 및 Network 정책은 트래픽이 시작될 때 Pod 수준에서 먼저 평가됩니다. EKS 네트워크 정책이 특정 도메인으로의 이그레스를 허용하면 Pod가 Route 53 Resolver에 도달하는 DNS 쿼리를 수행합니다. 이 시점에서 Route 53 DNS Firewall 규칙이 평가됩니다. DNS Firewall이 도메인 쿼리를 차단하면 EKS 네트워크 정책이 허용했더라도 DNS 해석이 실패하고 연결을 설정할 수 없습니다. 이는 보완적인 보안 레이어를 만듭니다. EKS DNS 기반 네트워크 정책은 애플리케이션 특정 접근 요구와 다중 테넌트 보안 경계에 대한 Pod 수준 이그레스 제어를 제공하고, DNS Firewall은 알려진 악성 도메인에 대한 VPC 차원 보호를 제공하며 조직 차원의 차단 목록을 시행합니다.

더 알아보기 (Learn more)

공식 문서