EKS Auto Mode에서 네트워크 정책 사용 - Amazon EKS
개요시작하기어떻게 작동하나요?고려 사항

이 페이지 개선에 도움 주기

이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 GitHub에서 이 페이지 편집 링크를 선택합니다.

EKS Auto Mode에서 네트워크 정책 사용

개요

고객이 EKS를 사용하여 애플리케이션 환경을 조정할 때 네트워크 트래픽 격리는 클러스터 내부 및 외부의 리소스에 대한 권한 없는 액세스를 방지하는 기본적인 방식으로 더 많이 사용되고 있습니다. 클러스터에서 여러 관련 없는 워크로드가 나란히 실행되는 다중 테넌트 환경에서 특히 중요합니다. Kubernetes 네트워크 정책을 사용하면 Kubernetes 워크로드의 네트워크 보안 태세 및 클러스터 외부 엔드포인트와의 통합을 강화할 수 있습니다. EKS Auto Mode는 다양한 유형의 네트워크 정책을 지원합니다.

계층 3 및 4 격리

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

사용 사례

  • 워크로드 간에 네트워크 트래픽을 분할하여 관련 애플리케이션만 서로 통신할 수 있도록 보장합니다.

  • 정책을 통해 네임스페이스 수준에서 테넌트를 격리하여 네트워크 분리를 적용합니다.

DNS 기반 적용

고객은 일반적으로 더 광범위한 분산 환경의 일부인 EKS에 워크로드를 배포합니다. 이 중 일부는 클러스터 외부의 시스템 및 서비스와 통신해야 합니다(노스바운드 트래픽). 이러한 시스템 및 서비스는 AWS 클라우드에 있거나 AWS 외부에 있을 수 있습니다. 도메인 이름 시스템(DNS) 기반 정책을 사용하면 포드에서 클러스터 외부 리소스 또는 엔드포인트로의 권한 없는 액세스를 방지하기 위해 보다 안정적이고 예측 가능한 접근 방식을 채택하여 보안 태세를 강화할 수 있습니다. 이 메커니즘을 사용하면 특정 IP 주소를 수동으로 추적하고 허용 목록에 추가하지 않아도 됩니다. DNS 기반 접근 방식으로 리소스를 보호하면 업스트림 서버 및 호스트에 대한 변경 중 보안 태세를 완화하거나 네트워크 정책을 수정하지 않고도 외부 인프라를 업데이트할 수 있는 유연성도 향상됩니다. 정규화된 도메인 이름(FQDN) 또는 DNS 도메인 이름과 일치하는 패턴을 사용하여 외부 엔드포인트로 송신 트래픽을 필터링할 수 있습니다. 이를 통해 특정 클러스터 외부 엔드포인트와 연결된 여러 하위 도메인으로 액세스를 확장할 수 있는 유연성이 추가됩니다.

사용 사례

  • Kubernetes 환경에서 클러스터 외부 엔드포인트로의 액세스를 필터링하기 위한 DNS 기반 접근 방식을 표준화합니다.

  • 다중 테넌트 환경에서 AWS 서비스에 대한 보안 액세스.

  • 하이브리드 클라우드 환경의 경우 포드에서 온프레미스 워크로드로의 네트워크 액세스를 관리합니다.

관리자 또는 클러스터 범위의 규칙

다중 테넌트 시나리오와 같은 일부 경우 고객은 전체 클러스터에 적용되는 네트워크 보안 표준을 적용해야 할 수 있습니다. 각 네임스페이스에 대해 고유한 정책을 반복적으로 정의하고 유지하는 대신 단일 정책을 사용하여 네임스페이스에 관계없이 클러스터의 여러 워크로드에 대한 네트워크 액세스 제어를 중앙에서 관리할 수 있습니다. 이러한 유형의 정책을 사용하면 계층 3 및 계층 4에서와 DNS 규칙을 사용할 때 적용되는 네트워크 필터링 규칙의 적용 범위를 확장할 수 있습니다.

사용 사례

  • EKS 클러스터의 모든 워크로드와 워크로드의 하위 집합에 대한 네트워크 액세스 제어를 중앙에서 관리합니다.

  • 전체 클러스터에서 기본 네트워크 보안 태세를 정의합니다.

  • 보다 운영 효율적인 방식으로 조직 보안 표준을 클러스터 범위로 확장합니다.

시작하기

사전 조건

  • EKS Auto Mode가 활성화된 Amazon EKS 클러스터

  • 클러스터에 연결하도록 구성된 kubectl

1단계: 네트워크 정책 컨트롤러 활성화

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

  1. 다음 콘텐츠가 포함된 enable-network-policy.yaml이라는 파일을 생성합니다.

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

  2. 클러스터에 ConfigMap 적용:

    kubectl apply -f enable-network-policy.yaml

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

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

3단계: 노드 클래스에서 네트워크 정책 에이전트 구성 조정(선택 사항)

선택적으로 새 노드 클래스를 생성하여 노드에서 네트워크 정책 에이전트의 기본 동작을 변경하거나 네트워크 정책 이벤트 로깅을 활성화할 수 있습니다. 이렇게 하려면 다음 단계를 따릅니다.

  1. 다음 내용을 사용하여 노드 클래스 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

  2. 클러스터에 노드 클래스 구성을 적용합니다.

    kubectl apply -f nodeclass-network-policy.yaml

  3. 노드 클래스가 생성되었는지 확인합니다.

    kubectl get nodeclass network-policy-config

  4. 이 노드 클래스를 사용하도록 노드 풀을 업데이트합니다. 자세한 내용은 EKS Auto Mode용 노드 풀 생성 섹션을 참조하세요.

어떻게 작동하나요?

DNS 기반 네트워크 정책

EKS Auto에서 DNS 기반 정책이 적용될 때 워크플로 그림
EKS Auto에서 DNS 기반 정책이 적용될 때 워크플로 그림

  1. 플랫폼 팀은 DNS 기반 정책을 EKS 클러스터에 적용합니다.

  2. 네트워크 정책 컨트롤러는 클러스터 내에서 정책 생성을 모니터링한 다음, 정책 엔드포인트를 조정할 책임이 있습니다. 이 사용 사례에서 네트워크 정책 컨트롤러는 생성된 정책의 허용 목록에 있는 도메인을 기반으로 DNS 요청을 필터링하도록 노드 에이전트에 지시합니다. 도메인 이름은 FQDN 또는 Kubernetes 리소스 구성에 정의된 패턴과 일치하는 도메인 이름을 사용하여 허용 목록에 추가됩니다.

  3. 워크로드 A는 클러스터 외부 엔드포인트의 IP를 확인하려고 시도합니다. DNS 요청은 먼저 네트워크 정책을 통해 적용된 허용 목록을 기반으로 이러한 요청을 필터링하는 프록시를 거칩니다.

  4. DNS 요청이 DNS 필터 허용 목록을 거치면 CoreDNS로 프록시됩니다.

  5. 그러면 CoreDNS는 외부 DNS 해석기(Amazon Route 53 Resolver)에 요청을 보내 도메인 이름 뒤의 IP 주소 목록을 가져옵니다.

  6. TTL이 있는 확인된 IP는 DNS 요청에 대한 응답으로 반환됩니다. 그런 다음 IP 계층 적용을 위한 다음 단계에서 사용되는 eBPF 맵에 이러한 IP가 기록됩니다.

  7. 그런 다음 포드 veth 인터페이스에 연결된 eBPF 프로브는 적용된 규칙에 따라 워크로드 A에서 클러스터 외부 엔드포인트로의 송신 트래픽을 필터링합니다. 이를 통해 포드는 허용 목록에 추가된 도메인의 IP로만 클러스터 외부 트래픽을 전송할 수 있습니다. 이러한 IP의 유효성은 외부 DNS 해석기(Amazon Route 53 Resolver)에서 검색된 TTL에 기반합니다.

애플리케이션 네트워크 정책 사용

ApplicationNetworkPolicy는 단일 사용자 지정 리소스 정의(CRD)를 사용하여 표준 Kubernetes 네트워크 정책의 기능을 네임스페이스 수준에서 DNS 기반 필터링과 결합합니다. 따라서 다음 경우에 ApplicationNetworkPolicy를 사용할 수 있습니다.

  1. IP 블록 및 포트 번호를 사용하여 네트워크 스택의 계층 3 및 4에서 제한 사항 정의.

  2. 네트워크 스택의 계층 7에서 작동하는 규칙을 정의하고 FQDN을 기반으로 트래픽을 필터링할 수 있습니다.

중요 사항: ApplicationNetworkPolicy를 사용하여 정의된 DNS 기반 규칙은 EKS Auto Mode에서 시작된 EC2 인스턴스에서 실행되는 워크로드에만 적용됩니다.

예제

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:
    - domainNames:
      - "myapp.mydomain.com"
    ports:
    - protocol: TCP
      port: 8080

Kubernetes 네트워크 수준에서는 이를 통해 role: backend 레이블이 지정된 'galaxy' 네임스페이스의 모든 포드에서 TCP 포트 8080의 도메인 이름 myapp.mydomain.com으로의 송신을 허용합니다. 또한 VPC에서 회사 데이터 센터로의 송신 트래픽에 대한 네트워크 연결을 설정해야 합니다.

온프레미스 애플리케이션과 통신하는 EKS Auto의 워크로드에 대한 그림

관리자(또는 클러스터) 네트워크 정책

EKS에서 네트워크 정책의 평가 순서에 대한 그림

클러스터 네트워크 정책 사용

ClusterNetworkPolicy를 사용하는 경우 관리자 티어 정책이 먼저 평가되며 이는 재정의할 수 없습니다. 관리자 티어 정책이 평가되면 표준 네임스페이스 범위의 정책을 사용하여 적용된 네트워크 분할 규칙을 실행합니다. 이는 ApplicationNetworkPolicy 또는 NetworkPolicy를 사용하여 수행할 수 있습니다. 마지막으로 클러스터 워크로드에 대한 기본 네트워크 제한 사항을 정의하는 기준 티어 규칙이 적용됩니다. 이러한 기준 티어 규칙은 필요한 경우 네임스페이스 범위의 정책에 의해 재정의 가능합니다.

예제

클러스터에 다른 테넌트 워크로드와 격리하려는 애플리케이션이 있습니다. 다른 네임스페이스의 클러스터 트래픽을 명시적으로 차단하여 민감한 워크로드 네임스페이스에 대한 네트워크 액세스를 방지할 수 있습니다.

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

  1. 관리자 티어 정책(먼저 평가됨): 모든 관리자 티어 ClusterNetworkPolicies는 다른 정책보다 먼저 평가됩니다. 관리자 티어 내에서 정책은 우선순위에 따라 처리됩니다(가장 낮은 우선순위 번호 먼저 처리됨). 작업 유형에 따라 다음 상황이 결정됩니다.

    • 거부 작업(가장 높은 우선순위): 거부 작업이 있는 관리자 정책이 트래픽과 일치하면 다른 정책에 관계없이 해당 트래픽이 즉시 차단됩니다. 추가 ClusterNetworkPolicy 또는 NetworkPolicy 규칙은 더 이상 처리되지 않습니다. 이를 통해 조직 전체의 보안 제어가 네임스페이스 수준 정책에 의해 재정의되지 않습니다.

    • 허용 작업: 거부 규칙을 평가한 후 허용 작업이 있는 관리자 정책은 우선순위에 따라 처리됩니다(가장 낮은 우선순위 번호 먼저 처리됨). 허용 작업이 일치하면 트래픽이 수락되고 추가 정책 평가가 수행되지 않습니다. 이러한 정책은 레이블 선택기를 기반으로 여러 네임스페이스에 액세스 권한을 부여하여 특정 리소스에 액세스할 수 있는 워크로드를 중앙에서 제어할 수 있습니다.

    • 통과 작업: 관리자 티어 정책에서 통과 작업은 의사 결정이 하위 티어로 위임합니다. 트래픽이 통과 규칙과 일치하면 평가는 해당 트래픽에 대한 나머지 모든 관리자 티어 규칙을 건너뛰고 NetworkPolicy 티어로 바로 진행합니다. 이를 통해 관리자는 특정 트래픽 패턴에 대한 제어를 애플리케이션 팀에 명시적으로 위임할 수 있습니다. 예를 들어 통과 규칙을 사용하여 외부 액세스에 대한 엄격한 제어를 유지하면서 네임스페이스 내 트래픽 관리를 네임스페이스 관리자에게 위임할 수 있습니다.

  2. 네트워크 정책 티어: 거부 또는 허용과 일치하는 관리자 티어 정책이 없거나 통과 작업이 일치하는 경우 네임스페이스 범위의 ApplicationNetworkPolicy 및 기존의 NetworkPolicy 리소스가 다음에 평가됩니다. 이러한 정책은 개별 네임스페이스 내에서 세분화된 제어를 제공하며 애플리케이션 팀이 관리합니다. 네임스페이스 범위의 정책은 관리자 정책보다 더 제한적일 수 있습니다. 관리자 정책의 거부 결정을 재정의할 수는 없지만 관리자 정책에서 허용하거나 전달하는 트래픽을 추가로 제한할 수 있습니다.

  3. 기준 티어 관리자 정책: 트래픽과 일치하는 관리자 또는 네임스페이스 범위의 정책이 없는 경우 기준 티어 ClusterNetworkPolicies가 평가됩니다. 이는 네임스페이스 범위의 정책으로 재정의할 수 있는 기본 보안 태세를 제공하므로 관리자는 조직 전체의 기본값을 설정하는 동시에 필요에 따라 팀에 사용자 지정할 수 있는 유연성을 제공할 수 있습니다. 기준 정책은 우선순위에 따라(가장 낮은 우선순위 번호 먼저) 평가됩니다.

  4. 기본 거부(정책이 일치하지 않는 경우):이러한 기본적으로 거부 동작은 명시적으로 허용된 연결만 허용되도록 보장하여 강력한 보안 태세를 유지 관리합니다.

최소 권한 원칙 적용

  • 제한적인 정책으로 시작하고 필요에 따라 점진적으로 권한 추가 - 먼저 클러스터 수준에서 기본적으로 거부 정책을 구현한 다음 정상 연결 요구 사항을 검증할 때 허용 규칙을 점진적으로 추가합니다. 이 접근 방식을 사용하면 팀이 각 외부 연결을 명시적으로 정당화하여 보다 안전하고 감사 가능한 환경을 생성할 수 있습니다.

  • 정기적으로 미사용 정책 규칙 감사 및 제거 - 애플리케이션이 진화하면서 시간이 지남에 따라 네트워크 정책이 누적될 수 있으며 공격 표면을 불필요하게 확장하는 더 이상 사용되지 않는 규칙이 남겨질 수 있습니다. 정기적인 검토 프로세스를 구현하여 더 이상 필요하지 않은 정책 규칙을 식별하고 제거하여 엄격하고 관리 가능한 보안 태세를 보장합니다.

  • 가능하면 광범위한 패턴 대신 특정 도메인 이름 사용 - *.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 방화벽과의 상호 작용

EKS 관리자 및 네트워크 정책은 트래픽이 시작될 때 포드 수준에서 먼저 평가됩니다. EKS 네트워크 정책이 특정 도메인으로의 송신을 허용하는 경우 포드는 Route 53 Resolver에 도달하는 DNS 쿼리를 수행합니다. 이때 Route 53 DNS 방화벽 규칙이 평가됩니다. DNS 방화벽이 도메인 쿼리를 차단하면 EKS 네트워크 정책에서 허용했더라도 DNS 확인에 실패하고 연결을 설정할 수 없습니다. 그래서 보완적인 보안 계층을 생성합니다. EKS DNS 기반 네트워크 정책은 애플리케이션 특정 액세스 요구 사항 및 다중 테넌트 보안 경계에 대한 포드 수준의 송신 제어를 제공하는 반면, DNS 방화벽은 알려진 악성 도메인에 대해 VPC 전반의 보호를 제공하고 조직 전체의 차단 목록을 적용합니다.