Amazon Web Services 한국 블로그
Amazon VPC CNI가 쿠버네티스 네트워크 폴리시를 지원합니다
지난 8월 말의 업데이트를 통해 Amazon VPC 컨테이너 네트워킹 인터페이스(CNI) 플러그인이 쿠버네티스 네트워크 폴리시를 기본 지원하게 되었습니다. 이제 Amazon VPC CNI를 사용하여 파드 네트워킹과 네트워크 폴리시를 모두 구현하는 것으로 쿠버네티스 클러스터의 트래픽을 보호할 수 있습니다. 네트워크 폴리시의 기본 지원은 컨테이너 로드맵에서 가장 많이 요청된 기능 중 하나였습니다.
기본적으로 쿠버네티스는 모든 파드가 제한 없이 서로 통신할 수 있도록 허용합니다. 쿠버네티스 네트워크 폴리시를 사용하면 파드 간 트래픽 흐름에 대한 규칙을 정의하고 적용할 수 있습니다. 이는 가상의 방화벽 역할을 하며, 파드 레이블, 네임스페이스, IP 주소, IP 블록(CIDR 범위) 및 포트와 같은 다양한 기준에 따라 ingress(즉, 들어오는 것) 및 egress(즉, 나가는 것) 네트워크 트래픽 규칙을 지정하여 클러스터를 세분화하고 보호할 수 있게 합니다. 지금까지 고객은 서드파티 네트워크 폴리시 플러그인을 사용해 네트워크 폴리시를 구현했으며, 이로 인해 운영 및 관리 오버헤드가 발생하는 경우가 많았습니다. Amazon VPC CNI의 통합 기능은 클러스터 구성 및 배포를 간소화합니다. 트래픽 흐름을 제한하면 확장 이슈에 대한 걱정 없이 더 강력한 보안 체제를 구축할 수 있습니다.
Amazon VPC CNI에서의 네트워크 폴리시 기본 지원으로, 이제 AWS에서 쿠버네티스를 실행할 때 민감한 워크로드를 격리하고 무단 액세스로부터 보호하는 정책을 생성할 수 있습니다. 이러한 수준의 세분화된 제어를 통해 권한이 부여된 파드만 서로 통신할 수 있도록 하는 최소 권한 원칙을 구현할 수 있습니다. 네트워크 폴리시는 Amazon EC2(Amazon Elastic Compute Cloud) 보안 그룹(Security Group, SG) 및 네트워크 액세스 제어 목록(Network Access Control List, NACL)과 같이 Amazon VPC에서 제공하는 보안 기능을 확장하는 심층 방어 메커니즘을 제공합니다.
Amazon Elastic Kubernetes Service(Amazon EKS)는 업스트림 쿠버네티스 네트워크 폴리시 API를 완벽하게 지원하여 호환성 및 쿠버네티스 표준 준수를 보장합니다. 즉, Amazon EKS 클러스터 내에서 네트워크 폴리시 API의 모든 기능을 사용할 수 있음을 뜻합니다. 업스트림 API에서 지원하는 다양한 식별자(identifiers)를 사용하여 정책을 유연하게 정의할 수 있습니다. 이를 통해 클러스터 내에서 보안과 격리를 강화하는 파드 간 통신을 정의할 수 있습니다.
작동 방식
쿠버네티스 네트워크 폴리시가 처음 도입되었을 때, 기본적이고 널리 채택된 구현방법은 iptables였습니다. iptables는 네트워크 폴리시를 적용하는 데 효과적이었지만, 쿠버네티스 클러스터의 규모의 확장에 따라 몇 가지 제한 사항이 발생했습니다. 다수의 iptables 규칙을 관리하는 것은 어려울 수 있으며, 각 패킷에 대한 규칙의 순차적 평가로 인해 규칙 수가 증가함에 따라 성능 문제가 발생할 수 있다는 것입니다.
이러한 문제를 해결하고 성능을 개선하기 위해 Amazon EKS는 extended Berkeley Packet Filter (eBPF)를 사용하여 네트워크 폴리시를 구현하는 향상된 접근 방식을 채택했습니다. 이 기술은 네트워크 폴리시의 대체 구현방식으로 최근 몇 년 동안 상당한 주목을 받고 있습니다. eBPF는 보다 효율적인 패킷 필터링을 제공하고 iptables과 비교할 때 전반적인 성능을 향상시킬 수 있는 잠재력을 제공합니다. 해당 방식에서는 커널 자체 내에서 직접 커스텀 코드를 실행할 수 있도록 지원하여 이러한 장점들을 달성합니다.
네트워크 폴리시의 구현을 위해 Amazon EKS에서 심리스하게 작동하는 세 가지 핵심 구성 요소가 도입되었습니다.
- 네트워크 폴리시 컨트롤러: Amazon EKS는 최신 버전의 Amazon VPC CNI를 통해 네트워크 폴리시 컨트롤러의 출시를 발표했습니다. 컨트롤러는 현재 공개적으로 사용할 수 있습니다. 신규 Amazon EKS 클러스터를 생성할 때 해당 기능이 활성화되면 네트워크 폴리시 컨트롤러가 쿠버네티스 컨트롤 플레인에 자동으로 설치됩니다. 이 컨트롤러는 클러스터 내에서 네트워크 폴리시 생성을 능동적으로 모니터링하고 폴리시 엔드포인트(Policy Endpoint)를 조정합니다. 그 후, 컨트롤러는 폴리시 엔드포인트를 통해 파드 정보를 게시하여 노드 에이전트가 노드에서 eBPF 프로그램을 생성하거나 업데이트하도록 지시합니다. 네트워크 폴리시 컨트롤러는 파드 프로비저닝과 병행하여 파드에 대한 정책을 구성하며, 그때까지 신규 파드는 기본 허용 정책을 적용받게 됩니다. 신규 파드로부터의, 혹은 신규 파드로의 모든 수신 및 송신 트래픽은 기존 정책과 맞춰질(reconcile) 때까지 허용됩니다. 자체 관리형 쿠버네티스 클러스터에서 네트워크 폴리시를 효과적으로 관리하려면 네트워크 폴리시 컨트롤러를 배포해야 합니다. 이와 관련하여, 이 포스팅의 실습 섹션에서 자체 관리형 클러스터에 대한 자세한 정보와 주요 고려 사항을 확인할 수 있습니다.
- 노드 에이전트: 최신 버전의 Amazon VPC CNI는 클러스터 내의 모든 노드에 CNI 바이너리 및 ipamd 플러그인과 함께 노드 에이전트도 설치합니다. 노드 에이전트는 VPC CNI와 함께 번들로 제공되며 aws-node라는 이름의 데몬셋에서 컨테이너로 실행됩니다. 이 노드 에이전트는 네트워크 폴리시가 클러스터에 적용될 때 컨트롤러로부터 정책 엔드포인트를 수신합니다. 노드 에이전트는 네트워크 폴리시를 원활하게 적용할 수 있는 기반을 마련하는 eBPF 프로그램을 관리하는 데 중요한 역할을 합니다.
- eBPF SDK(소프트웨어 개발 키트): 추가 지원 및 운영을 위해 Amazon VPC CNI는 노드에서 eBPF 프로그램과 상호 작용할 수 있는 직관적인 인터페이스를 제공하는 SDK를 포함합니다. 해당 SDK를 사용하면 연결 문제를 식별하고 해결하는 데 도움이 되는 런타임 자가 분석, 추적 및 eBPF 실행 분석을 수행할 수 있습니다.
네트워크 폴리시는 v1.25 이상을 사용하는 새로운 Amazon EKS(IPv4 및 IPv6) 클러스터에서 지원됩니다. Amazon EKS는 모든 기존 클러스터를 해당 쿠버네티스 마이너 버전에 대한 최신 Amazon EKS 플랫폼 버전으로 자동 업그레이드합니다. 네트워크 폴리시 기능을 지원하는 플랫폼 버전의 자동 업그레이드가 기존 클러스터에 롤아웃될 때 네트워크 폴리시를 적용할 수 있습니다. 플랫폼 버전에 대한 자세한 내용은 Amazon EKS 사용자 가이드를 참고 바랍니다.
클러스터에서 네트워크 폴리시를 활성화하려면 클러스터가 Amazon VPC CNI 버전 1.14.0 이상을 실행 중인지 확인합니다. 신규 클러스터를 생성할 때 Amazon VPC CNI 버전 1.14.0 이상을 지정할 수 있으며, Amazon VPC CNI 버전 1.14.0으로 만들지 않은 클러스터의 경우 Amazon VPC CNI를 추후 업데이트할 수 있습니다. 기존 클러스터에 대한 플랫폼 버전 업데이트가 완료되면 VPC CNI를 네트워크 폴리시가 지원되는 버전으로 업데이트해야 합니다.
출시 시점에서, 네트워크 폴리시는 커널 버전 5.10 이상을 사용하는 Amazon EKS-optimized Amazon Linux AMI, Amazon EKS-optimized Bottlerocket AMI 및 Amazon EKS-optimized Ubuntu Linux AMI에서 지원됩니다. 커널 버전 5.10 이상을 사용하여 구축된 Amazon EKS-optimized AMI는 노드에 네트워크 폴리시를 적용하는 데 필요한 eBPF 파일 시스템인 /sys/fs/bpf를 자동으로 마운트합니다. 기존 클러스터의 경우, Amazon EKS 플랫폼 버전이 업데이트되면 노드를 최신 버전의 Amazon EKS-optimized AMI로 업데이트하는 것이 좋습니다. 커널 버전 5.10 이하를 사용하는 노드의 경우, Amazon EKS 사용자 가이드의 eBPF 파일 시스템 마운트 방법 안내를 참고 바랍니다. eBPF 시스템 지원을 통해 사용자 지정 AMI를 생성하는 방법에 대한 안내는 Amazon EKS-optimized Amazon Linux AMI 빌드 스크립트를 참고 바랍니다.
시작하기
네트워크 폴리시 기능은 쿠버네티스 마이너 버전 1.25 이상을 실행하는 클러스터에서 지원되지만, 시작 시에는 기본적으로 비활성화되어 있습니다. 클러스터를 생성할 때 Amazon VPC CNI 구성 파라미터를 사용하여 클러스터에 대한 네트워크 폴리시를 활성화할 수 있습니다.
Amazon VPC CNI가 IP 주소를 관리하기 위해서는 AWS Identity and Access Management(AWS IAM) 권한이 필요합니다. Amazon EKS는 AmazonEKS_CNI_Policy 라는 이름의 관리형 정책에 정의된 권한으로 별도의 AWS IAM 역할을 생성한 후, IRSA(서비스 어카운트에 대한 AWS IAM 역할)를 사용하여 해당 IAM 역할을 VPC CNI와 연결할 것을 권장합니다. IRSA에는 OIDC(OpenID Connect) 엔드포인트가 필요하기 때문에, 클러스터 생성 시에 IAM OIDC 공급자를 생성할 것입니다. 자세한 내용은 서비스 어카운트에 IAM 역할을 사용하도록 쿠버네티스용 Amazon VPC CNI 플러그인 구성을 참고 바랍니다.
다음 구성을 복사하여 cluster.yaml이라는 파일에 저장합니다.
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: network-policy-demo
version: "1.27"
region: us-west-2
iam:
withOIDC: true
vpc:
clusterEndpoints:
publicAccess: true
privateAccess: true
addons:
- name: vpc-cni
version: 1.14.0
attachPolicyARNs: #optional
- arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
configurationValues: |-
enableNetworkPolicy: "true"
- name: coredns
- name: kube-proxy
managedNodeGroups:
- name: x86-al2-on-demand
amiFamily: AmazonLinux2
instanceTypes: [ "m6i.xlarge", "m6a.xlarge" ]
minSize: 0
desiredCapacity: 2
maxSize: 6
privateNetworking: true
disableIMDSv1: true
volumeSize: 100
volumeType: gp3
volumeEncrypted: true
tags:
team: "eks"eksctl create cluster -f cluster.yaml클러스터 생성이 완료될 때까지 기다린 후, Amazon VPC CNI가 노드 에이전트를 실행하는지 확인합니다.
kubectl get ds -n kube-system aws-node -o jsonpath='{.spec.template.spec.containers[*].name}{"\n"}'출력 결과:
aws-node aws-eks-nodeagent
eBPF SDK 사용
최신 버전의 Amazon VPC CNI는 노드에서 eBPF 프로그램과 상호 작용할 수 있는 인터페이스를 지원하는 SDK를 제공합니다. SDK는 aws-node를 노드에 배포할 때 설치됩니다. 노드의 /opt/cni/bin 디렉터리 아래에 설치된 SDK 바이너리를 확인할 수 있습니다. 연결 문제를 확인하기 위해 해당 SDK를 사용하는 것을 고려해보십시오. 파드를 위한 eBPF 프로그램이 노드 상에서 생성되었는지 확인합니다. Amazon EC2 콘솔에서 AWS Systems Manager (AWS SSM)로 노드에 접속하면 이를 확인할 수 있습니다.
출시 시점에서, SDK는 eBPF 프로그램 및 맵 검사와 같은 주요 기능을 지원합니다. 구체적인 사용에 대한 요청사항이 있는 경우 이 링크에서 GitHub 이슈를 생성하여 알려주시기 바랍니다. 사용자 가이드를 방문하여 SDK 사용법을 알아볼 수 있습니다.
sudo /opt/cni/bin/aws-eks-na-cli ebpf progs샘플 애플리케이션 배포
이제 default 네임스페이스에 demo-app이라는 샘플 NGINX 애플리케이션과 간단한 클라이언트 애플리케이션을 배포하겠습니다. 또한 default 네임스페이스가 아닌 another-ns라는 네임스페이스에 또 다른 클라이언트 애플리케이션을 생성하겠습니다.
git clone https://github.com/aws-samples/eks-network-policy-examples.git
cd eks-network-policy-examples
kubectl apply -f advanced/manifests/모든 파드가 실행 중(Running) 상태가 될 때까지 기다립니다.
kubectl get pods --all-namespaces --watch네트워크 폴리시 설치
기본적으로 쿠버네티스는 모든 파드가 다른 모든 파드와 자유롭게 통신할 수 있도록 허용합니다. 파드에 쿠버네티스 네트워크 폴리시가 적용되지 않은 경우, 파드와 주고받는 모든 트래픽이 허용됩니다.
접근 확인 및 모든 Ingress 및 Egress 허용하기
별도의 터미널을 사용하여 이전 단계에서 배포한 클라이언트 파드와의 연결을 확인할 수 있습니다.
kubectl exec -it client-one -- curl demo-appAPI 호출이 성공했음을 나타내는 응답이 표시됩니다.
모든 트래픽 거부
demo-app 애플리케이션에 모든 네임스페이스에 대한 모든 트래픽 거부 정책을 적용하여 격리를 활성화해 보겠습니다.
kubectl apply -f advanced/policies/01-deny-all-ingress.yaml네트워크 폴리시에서 모든 파드를 선택하여 demo-app으로 유입되는 모든 트래픽이 거부됩니다.
kubectl exec -it client-one -- curl --max-time 3 demo-app위 명령의 결과로 타임 아웃이 발생합니다.
curl: (28) Connection timed out after 3001 milliseconds command terminated with exit code 28
동일한 네임스페이스에서 Ingress 허용
다음 단계에서는 동일한 네임스페이스 내의 client-one에서 demo-app으로의 Ingress 트래픽을 허용합니다.
kubectl apply -f advanced/policies/03-allow-ingress-from-samens-client-one.yaml(역자주: 제어 대상에 대해 중복으로 허용 설정이 되는 경우 합집합으로 연산됩니다. 위 명령어 실행 이전, advanced/policies/02-allow-ingress-from-samens.yaml 파일을 적용할 경우, 동일한 네임스페이스에 대한 트래픽을 모두 허용하는 설정이 이미 적용 되었기 때문에 advanced/policies/03-allow-ingress-from-samens-client-one.yaml 파일에서 정의한 client-one에 대한 트래픽 뿐만 아니라 client-two에 대한 Ingress 트래픽도 동작하게 됩니다.)
다음 명령어를 실행하면 NGINX 시작 페이지의 HTML을 반환합니다.
kubectl exec -it client-one -- curl --max-time 3 demo-app(역자주: 아래 명령어를 실행하면 Ingress를 허용하지 않은 client-two에서 demo-app으로의 Ingress traffic은 거부되는 것을 알 수 있습니다.)
kubectl exec -it client-two -- curl --max-time 3 demo-appanother-ns 네임스페이스로부터의 Ingress 트래픽 허용
다음으로 another-ns 네임스페이스로부터의 트래픽을 허용하도록 하겠습니다.
kubectl apply -f advanced/policies/04-allow-ingress-from-xns.yaml이제 another-ns 네임스페이스의 클라이언트에서 데모 앱에 액세스할 수 있어야 합니다. 다음 명령어를 실행하면 웰컴 메시지가 반환됩니다.
kubectl exec -it -n another-ns another-client-one -- curl --max-time 3 demo-app.defaultEgress 트래픽 거부
기본 네임스페이스의 client-one 파드에서 모든 Egress 트래픽의 격리를 적용합니다.
kubectl apply -f advanced/policies/06-deny-egress-from-client-one.yamlclient-one의 DNS 조회를 포함한 모든 Egress 트래픽이 거부된 것을 확인할 수 있습니다.
kubectl exec -it client-one -- nslookup demo-appEgress 트래픽 허용
DNS 트래픽을 포함하여 여러 포트 및 네임스페이스에서 송신하도록 허용해 보겠습니다.
kubectl apply -f advanced/policies/08-allow-egress-to-demo-app.yaml이제 DNS 및 demo-app에 대한 Egress 트래픽이 허용됩니다.
kubectl exec -it client-one -- curl --max-time 3 demo-app주요 고려 사항
파드용 네트워크 폴리시 및 보안 그룹
IPv4 모드의 Amazon VPC CNI는 파드의 보안 그룹(Security groups for pods)이라는 강력한 기능을 제공합니다. 해당 기능을 사용하면 Amazon EC2 보안 그룹을 사용하여 노드에 배포된 파드에 대한 인바운드 및 아웃바운드 네트워크 트래픽을 관리하는 규칙을 정의할 수 있습니다. 파드용 보안 그룹과 네트워크 폴리시를 조합하여 사용하면 보안 태세를 강화할 수 있습니다. 네트워크 폴리시를 활성화하면, 파드의 보안 그룹은 심층 방어 전략의 추가 레이어 역할을 하게 됩니다. 네트워크 폴리시를 사용하여 클러스터 내의 네트워크 트래픽 흐름에 대해 세분화된 제어를 적용할 수 있으며, 파드의 보안 그룹은 Amazon의 시맨틱 제어를 활용하여 Amazon RDS 데이터베이스와 같은 Virtual Private Cloud(VPC) 내의 리소스와의 통신을 관리함으로써 추가적인 보호 기능을 제공합니다. Amazon EKS는 네트워크 폴리시를 사용하여 파드 간의 네트워크 통신을 제한하는 것으로 공격 표면을 줄이고, 잠재적인 취약성을 최소화할 것을 강력히 권장합니다. 네트워크 폴리시와 함께 보안 그룹을 사용하는 방법에 대한 전체 가이드는 Amazon EKS 모범 사례를 참고 바랍니다.
네트워크 폴리시 및 서드파티 CNI 플러그인
아마존 VPC CNI는 Kubernetes NetworkPolicy API를 사용하여 정의된 네트워크 폴리시의 지원을 제공합니다. 현재 파드 네트워킹을 위해 서드파티 CNI 플러그인을 실행 중인 클러스터에서 네트워크 폴리시 기능을 활성화하기 위해서는 Amazon VPC CNI로 마이그레이션해야 한다는 점을 반드시 유의해야 합니다.
이 포스팅의 작성 시점 기준으로, Amazon VPC CNI는 서드파티 네트워크 폴리시 플러그인을 Amazon VPC CNI로 인플레이스 마이그레이션을 지원하지 않습니다. 원활한 전환을 위해 Amazon EKS에서는 Amazon VPC CNI 네트워크 폴리시를 사용하도록 설정하기 이전에 기존의 서드파티 NetworkPolicy API를 Kubernetes NetworkPolicy API로 변환할 것을 권장합니다. 프로덕션 환경에 변경 사항을 적용하기 전에는 별도의 테스트 클러스터에서 마이그레이션 된 정책을 테스트할 것을 권장합니다. 이를 통해 파드 통신 동작의 잠재적인 문제나 불일치를 식별하고 해결할 수 있습니다.
일관성을 유지하고 예기치 않은 파드 통신 동작을 방지하려면, 주어진 시간에 하나의 네트워크 폴리시 플러그인만 실행하는 것이 좋습니다. 최신 버전의 Amazon VPC CNI로 업그레이드하기 전 기존의 서드파티 네트워크 폴리시 CNI 플러그인을 모두 제거해야 합니다. 추가적으로, 워커 노드를 재활용할 경우 노드에 남아 있는 변경 사항(예: iptables 또는 eBPF 프로그램)을 제거하는 데 도움이 됩니다. Amazon VPC CNI 네트워크 폴리시로 마이그레이션하기 위한 자세한 순서는 이 링크에서 제공되는 설명을 참고 바랍니다. k8s-network-policy-migrator 오픈소스 저장소에서 제공되는 스크립트를 사용하여 서드파티 NetworkPolicy를 쿠버네티스 NetworkPolicy 아티팩트로 변환할 수 있습니다. 이러한 리소스는 Amazon EKS의 공식 지원 제품은 아니지만, Amazon VPC CNI 네트워크 폴리시 지원으로의 성공적인 전환을 보장하기 위해 마이그레이션 프로세스를 간소화하려는 목표를 달성하려는 수준 내에서 노력을 다하고 있습니다.
자체 관리형 쿠버네티스 클러스터
최신 버전의 Amazon VPC CNI를 사용하면, AWS의 자체 관리형 쿠버네티스 클러스터에 네트워크 폴리시를 적용할 수 있습니다. Amazon VPC CNI를 업데이트하는 것 외에도, 네트워크 폴리시를 활성화하기 위해서는 자체 관리형 쿠버네티스 클러스터에 Amazon 네트워크 폴리시 컨트롤러를 설치해야 합니다. 네트워크 폴리시 컨트롤러를 배포하려면 이 GitHub 저장소에서 제공된 가이드를 참고 바랍니다. 여기서 주의할 점은 Amazon VPC CNI와 네트워크 폴리시 컨트롤러는 현재 서드파티 네트워크 폴리시 플러그인 및 사용자 정의 네트워크 폴리시 오브젝트의 인플레이스 마이그레이션을 지원하지 않는다는 점입니다. 따라서 위에서 언급한 절차에 따라 Amazon VPC CNI 네트워크 폴리시로의 마이그레이션을 진행합니다.
리소스 정리
향후 비용 발생을 방지하려면 실습을 위해 생성한 Amazon EKS 클러스터를 포함한 모든 리소스를 삭제합니다. 이 작업은 클러스터를 삭제하는 것 뿐만 아니라 노드 그룹도 삭제합니다.
eksctl delete cluster -f cluster.yaml결론
이 포스팅에서는 로드맵에서 가장 요청이 많았던 기능 중 하나인 쿠버네티스 네트워크 폴리시 지원을 이제 Amazon EKS에서 사용할 수 있다는 것을 보여드렸습니다. 또한, 서드파티 네트워크 폴리시 플러그인을 관리할 필요 없이 통신을 세밀하게 제어하고, 워크로드를 격리하고, AWS 쿠버네티스 클러스터의 전반적인 보안을 강화할 수 있는 방법을 보여드렸습니다.
네트워크 폴리시 도입을 시작할 때, Amazon EKS는 애플리케이션의 특정 보안 요구 사항을 염두에 두고 새로운 위협에 앞서 나가기 위해 정기적으로 정책을 검토하고 업데이트할 것을 권장합니다. 신중한 계획과 구현을 통해 무단 액세스로부터 애플리케이션과 데이터를 보호하기 위한 쿠버네티스 네트워크 폴리시의 잠재력을 최대한 활용할 수 있습니다. 권장 사항과 추가 고려 사항은 Amazon EKS 모범 사례 가이드를 참고 바랍니다.
Amazon VPC CNI에 대한 설치 가이드는 Amazon EKS 사용자 가이드를 참고 바랍니다. Amazon VPC CNI 플러그인에 대해 GitHub의 AWS 컨테이너 로드맵에 댓글 혹은 이슈를 생성하여 피드백을 제출할 수 있습니다. 계속해서 기능을 발전시키고 eBPF 기술을 활용하여 Amazon VPC CNI 내의 모니터링 및 가시성 기능을 제공할 수 있는 추가적인 방법을 모색하고 있으니 계속 지켜봐 주시기 바랍니다.
– Srinivas Jasti, Senior Product Manager, Amazon Elastic Kubernetes Service
– Sheetal Joshi, Principal Developer Advocate, Amazon Elastic Kubernetes Service
이 글은 AWS Container Blog의 Amazon VPC CNI now supports Kubernetes Network Policies를 박진이 솔루션즈 아키텍트가 한국어로 번역 및 편집한 글입니다.