**이 페이지 개선에 도움 주기** 이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다. # Amazon EKS의 보안 AWS은 클라우드 보안을 가장 중요하게 생각합니다. AWS 고객으로서 여러분은 가장 높은 보안 요구 사항을 충족하기 위해 설계된 데이터 센터 및 네트워크 아키텍처의 혜택을 받게 됩니다. 보안은 AWS과 사용자의 공동 책임입니다. [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)은 이 사항을 클라우드 내** 보안 및 클라우드**의 보안으로 설명합니다. + **클라우드의 보안** – AWS는 AWS 클라우드에서 AWS 서비스를 실행하는 인프라 보호를 책임집니다. Amazon EKS의 경우, AWS가 제어 영역 노드와 `etcd` 데이터베이스를 포함한 Kubernetes 제어 영역을 책임집니다. 서드 파티 감사원은 정기적으로 [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/)의 일환으로 보안 효과를 테스트하고 검증합니다. Amazon EKS에 적용되는 규정 준수 프로그램에 대한 자세한 내용은 [규정 준수 프로그램 제공 범위 내 AWS 서비스](https://aws.amazon.com/compliance/services-in-scope/)를 참조하세요. + **클라우드 내부의 보안** - 고객의 책임에는 다음 영역이 포함됩니다. + Amazon EKS 제어 영역에서 고객 VPC로 트래픽을 전달할 수 있는 보안 그룹의 구성을 포함한 데이터 영역의 보안 구성 + 노드와 컨테이너 자체의 구성 + 노드 운영 체제(업데이트 및 보안 패치 포함) + 기타 관련 애플리케이션 소프트웨어: + 방화벽 규칙과 같은 네트워크 컨트롤 설정 및 관리 + IAM을 단독 또는 추가로 이용하여 플랫폼 수준의 자격 증명 및 액세스 관리 + 데이터의 민감도, 회사 요구 사항, 관련 법률 및 규정 Amazon EKS는 규제 대상이며 민감한 애플리케이션에 대한 여러 규정 준수 프로그램의 인증을 받았습니다. Amazon EKS는 [SOC](https://aws.amazon.com/compliance/soc-faqs/), [PCI](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/), [ISO](https://aws.amazon.com/compliance/iso-certified/), [FedRAMP-Moderate](https://aws.amazon.com/compliance/fedramp/), [IRAP](https://aws.amazon.com/compliance/irap/), [C5](https://aws.amazon.com/compliance/bsi-c5/), [K-ISMS](https://aws.amazon.com/compliance/k-isms/), [ENS High](https://aws.amazon.com/compliance/esquema-nacional-de-seguridad/), [OSPAR](https://aws.amazon.com/compliance/OSPAR/), [HITRUST CSF](https://aws.amazon.com/compliance/hitrust/)와 호환되며, [HIPAA](https://aws.amazon.com/compliance/hipaa-compliance/) 적격 서비스입니다. 자세한 내용은 [Amazon EKS에서 액세스 제어가 작동하는 방식 알아보기](cluster-auth.md) 섹션을 참조하세요. 이 문서는 Amazon EKS를 사용할 때 공동 책임 모델을 적용하는 방법을 이해하는 데 도움이 됩니다. 다음 주제에서는 보안 및 규정 준수 목적에 맞게 Amazon EKS를 구성하는 방법을 보여줍니다. 또한 Amazon EKS 리소스를 모니터링하고 보호하는 데 도움이 되는 다른 AWS 서비스를 사용하는 방법을 배우게 됩니다. **참고** Linux 컨테이너는 컨테이너가 액세스할 수 있는 항목을 제한하는 데 도움이 되는 제어 그룹(cgroups)과 네임스페이스로 구성되지만 모든 컨테이너는 호스트 Amazon EC2 인스턴스와 동일한 Linux 커널을 공유합니다. 컨테이너를 루트 사용자(UID 0)로 실행하거나 호스트 네트워크 또는 호스트 PID 네임스페이스와 같은 호스트 리소스 또는 네임스페이스에 대한 액세스 권한을 컨테이너에 부여하는 것은 권장하지 않습니다. 이렇게 하면 컨테이너가 제공하는 격리의 효과가 떨어지기 때문입니다. **Topics** + [모범 사례로 Amazon EKS 클러스터 보호](security-best-practices.md) + [Amazon EKS에서 취약성 분석](configuration-vulnerability-analysis.md) + [Amazon EMR 클러스터에서 규정 준수 검증](compliance.md) + [Amazon Elastic Kubernetes Service에 대한 보안 고려 사항](security-eks.md) + [Kubernetes의 보안 고려 사항](security-k8s.md) + [Amazon EKS Auto Mode의 보안 고려 사항](auto-security.md) + [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) + [Amazon EKS용 자격 증명 및 액세스 관리](security-iam.md) # 모범 사례로 Amazon EKS 클러스터 보호 Amazon EKS 보안 모범 사례는 *Amazon EKS 모범 사례 가이드*의 [보안 모범 사례](https://docs.aws.amazon.com/eks/latest/best-practices/security.html)에 나와 있습니다. # Amazon EKS에서 취약성 분석 보안은 Kubernetes 클러스터 및 애플리케이션을 구성하고 유지 관리하는 데 중요한 고려 사항입니다. 다음에는 EKS 클러스터의 보안 구성을 분석하기 위한 리소스, 취약성을 확인하기 위한 리소스, 해당 분석을 수행할 수 있는 AWS 서비스와의 통합이 나열되어 있습니다. ## Amazon EKS에 대한 Center for Internet Security(CIS) 벤치마크 [Center for Internet Security(CIS) Kubernetes 벤치마크](https://www.cisecurity.org/benchmark/kubernetes/)는 Amazon EKS 보안 구성에 대한 지침을 제공합니다. 이 벤치마크의 기능: + Kubernetes 구성 요소의 보안 구성을 담당하는 Amazon EC2 노드(관리형 노드 및 자체 관리형 노드 모두)에 적용할 수 있습니다. + Amazon EKS를 사용할 때 Kubernetes 클러스터와 노드를 안전하게 구성할 수 있도록 커뮤니티에서 승인한 표준 방법을 제공합니다. + 제어 플레인 로깅 구성, 노드 보안 구성, 정책 및 관리형 서비스의 4개 섹션으로 구성됩니다. + 현재 Amazon EKS에서 사용할 수 있는 모든 Kubernetes 버전을 지원하며, Kubernetes 클러스터에서 CIS 벤치마크를 사용하여 구성을 확인하기 위한 표준 오픈 소스 도구인 [kube-bench](https://github.com/aquasecurity/kube-bench)를 사용하여 실행할 수 있습니다. 자세한 내용은 [CIS Amazon EKS 벤치마크 소개](https://aws.amazon.com/blogs/containers/introducing-cis-amazon-eks-benchmark)를 참조하세요. CIS 벤치마킹된 AMI로 노드 그룹을 업데이트하는 자동 `aws-sample` 파이프라인은 [EKS 최적화 AMI 강화 파이프라인](https://github.com/aws-samples/pipeline-for-hardening-eks-nodes-and-automating-updates)을 참조하세요. ## Amazon EKS 플랫폼 버전 Amazon EKS *플랫폼 버전*은 활성화된 Kubernetes API 서버 플래그와 현재 Kubernetes 패치 버전 등 클러스터 컨트롤 플레인의 기능을 나타냅니다. 새 클러스터는 최신 플랫폼 버전과 함께 배포됩니다. 자세한 내용은 [EKS 플랫폼 버전](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)을 참조하세요. 새로운 Kubernetes 버전으로 [Amazon EKS 클러스터를 업데이트](update-cluster.md)할 수 있습니다. Amazon EKS에서 새로운 Kubernetes 버전을 사용할 수 있게 되면 미리 클러스터를 업데이트하여 최신 버전을 사용하는 것이 좋습니다. EKS의 Kubernetes 버전에 대한 자세한 내용은 [Amazon EKS 지원 버전](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) 섹션을 참조하세요. ## 운영 체제 취약성 목록 ### AL2023 취약성 목록 [Amazon Linux 보안 센터](https://alas.aws.amazon.com/alas2023.html)에서 Amazon Linux 2023의 보안 또는 프라이버시 이벤트를 추적하거나 관련 [RSS 피드](https://alas.aws.amazon.com/AL2023/alas.rss)를 구독하세요. 보안 및 프라이버시 이벤트에는 영향을 받는 문제의 개요, 패키지, 인스턴스 업데이트로 문제를 해결하는 방법이 포함됩니다. ### Amazon Linux 2 취약성 목록 [Amazon Linux 보안 센터](https://alas.aws.amazon.com/alas2.html)에서 Amazon Linux 2의 보안 또는 프라이버시 이벤트를 추적하거나 관련 [RSS 피드](https://alas.aws.amazon.com/AL2/alas.rss)를 구독하세요. 보안 및 프라이버시 이벤트에는 영향을 받는 문제의 개요, 패키지, 인스턴스 업데이트로 문제를 해결하는 방법이 포함됩니다. ## Amazon Inspector로 노드 탐지 [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html)를 사용하여 노드의 의도하지 않은 네트워크 액세스 가능성과 이러한 Amazon EC2 인스턴스 취약성을 검사할 수 있습니다. ## Amazon GuardDuty로 클러스터 및 노드 탐지 Amazon GuardDuty는 AWS 환경 내 계정, 컨테이너, 워크로드 및 데이터를 보호하는 데 도움이 되는 위협 감지 서비스입니다. 다른 기능 중에서도 GuardDuty는 EKS 클러스터에 대한 잠재적 위협을 탐지하는 두 가지 기능인 **EKS Protection과 **런타임 모니터링을 제공합니다. 자세한 내용은 [Amazon GuardDuty로 위협 탐지](integration-guardduty.md) 섹션을 참조하세요. # Amazon EMR 클러스터에서 규정 준수 검증 AWS 서비스가 특정 규정 준수 프로그램의 범위 내에 있는지 확인하려면 [규정 준수 프로그램별 범위 내 AWS 서비스](https://aws.amazon.com/compliance/services-in-scope/)를 참조하고 관심 있는 규정 준수 프로그램을 선택하세요. 일반 정보는 [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/)을 참조하세요. AWS Artifact를 사용하여 타사 감사 보고서를 다운로드할 수 있습니다. 자세한 내용은 [AWS Artifact의 보고서 다운로드](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)를 참조하세요. AWS 서비스를 사용할 때 규정 준수 책임은 데이터의 민감도, 회사의 규정 준수 목표, 관련 법률 및 규정에 따라 결정됩니다. AWS는 규정 준수를 지원하기 위해 다음과 같은 리소스를 제공합니다. + [보안 규정 준수 및 거버넌스](https://aws.amazon.com/solutions/security/security-compliance-governance/) - 이러한 솔루션 구현 가이드에서는 아키텍처 고려 사항을 설명하고 보안 및 규정 준수 기능을 배포하는 단계를 제공합니다. + [HIPAA 적격 서비스 참조](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/) - HIPAA 적격 서비스가 나열되어 있습니다. 모든 AWS 서비스가 HIPAA에 적합한 것은 아닙니다. + [AWS 규정 준수 리소스](https://aws.amazon.com/compliance/resources/) – 사용자의 업계와 위치에 해당할 수 있는 워크북 및 안내서 모음입니다. + [AWS 고객 규정 준수 가이드](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf) - 규정 준수의 관점에서 공동 책임 모델을 이해합니다. 이 가이드에서는 AWS 서비스를 보호하기 위한 모범 사례를 요약하고 여러 프레임워크(미국 표준 기술 연구소(NIST), 결제 카드 산업 보안 표준 위원회(PCI), 국제 표준화기구(ISO) 등)에서 보안 제어에 대한 지침을 매핑합니다. + *AWS 구성 개발자 가이드*의 [규칙으로 리소스 평가하기](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) - AWS 구성 서비스는 리소스 구성이 내부 관행, 업계 가이드라인 및 규정을 얼마나 잘 준수하는지 평가합니다. + [AWS 보안 허브](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)- 이 AWS 서비스는 AWS 내의 보안 상태에 대한 포괄적인 보기를 제공합니다. Security Hub는 보안 컨트롤을 사용하여 AWS리소스를 평가하고 보안 업계 표준 및 모범 사례에 대한 규정 준수를 확인합니다. 지원되는 서비스 및 제어 목록은 [Security Hub 제어 참조](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html)를 참조하세요. + [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) - 이 AWS 서비스는 의심스럽고 악의적인 활동이 있는지 환경을 모니터링하여 AWS 계정, 워크로드, 컨테이너 및 데이터에 대한 잠재적 위협을 탐지합니다. GuardDuty는 특정 규정 준수 프레임워크에서 요구하는 침입 탐지 요구 사항을 충족하여 PCI DSS와 같은 다양한 규정 준수 요구 사항을 따르는 데 도움을 줄 수 있습니다. + [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) – 이 AWS 서비스는 AWS 사용량을 지속적으로 감사하여 위험과 규정 및 산업 표준의 준수를 관리하는 방법을 간소화하는 데 도움이 됩니다. # Amazon Elastic Kubernetes Service에 대한 보안 고려 사항 다음은 Amazon EKS에 영향을 미치는 클라우드 보안 고려 사항입니다. **Topics** + [Amazon EKS의 인프라 보안](infrastructure-security.md) + [Amazon EKS 클러스터에서 복원력 이해](disaster-recovery-resiliency.md) + [Amazon EKS의 교차 서비스 혼동된 대리자 예방](cross-service-confused-deputy-prevention.md) # Amazon EKS의 인프라 보안 관리형 서비스인 Amazon Elastic Kubernetes Service는 AWS 글로벌 네트워크 보안으로 보호됩니다. AWS 보안 서비스와 AWS의 인프라 보호 방법에 대한 자세한 내용은 [AWS 클라우드 보안](https://aws.amazon.com/security/)을 참조하세요. 인프라 보안에 대한 모범 사례를 사용하여 AWS 환경을 설계하려면 *보안 원칙 AWS Well‐Architected Framework*의 [인프라 보호](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)를 참조하세요. AWS에서 게시한 API 호출을 사용하여 네트워크를 통해 Amazon EKS에 액세스합니다. 고객은 다음을 지원해야 합니다. + Transport Layer Security(TLS) TLS 1.2는 필수이며 TLS 1.3을 권장합니다. + DHE(Ephemeral Diffie-Hellman) 또는 ECDHE(Elliptic Curve Ephemeral Diffie-Hellman)와 같은 완전 전송 보안(PFS)이 포함된 암호 제품군 Java 7 이상의 최신 시스템은 대부분 이러한 모드를 지원합니다. 또한 요청은 액세스 키 ID 및 IAM 위탁자와 관련된 보안 암호 액세스 키를 사용하여 서명해야 합니다. [AWS 보안 토큰 서비스](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)(AWS STS)를 사용하여 요청에 서명하기 위한 임시 보안 자격 증명을 생성할 수도 있습니다. Amazon EKS 클러스터를 생성할 때 클러스터가 사용할 VPC 서브넷을 지정합니다. Amazon EKS에는 최소 2개의 가용 영역에 있는 서브넷이 필요합니다. Kubernetes가 프라이빗 서브넷에 있는 노드에서 실행되는 포드로 트래픽을 로드 밸런싱하는 퍼블릭 서브넷에 퍼블릭 로드 밸런서를 생성할 수 있도록 퍼블릭 및 프라이빗 서브넷이 있는 VPC를 사용하는 것이 좋습니다. VPC 고려 사항에 대한 자세한 내용은 [VPC 및 서브넷에 대한 Amazon EKS 네트워킹 요구 사항 보기](network-reqs.md) 섹션을 참조하세요. [Amazon EKS 시작하기](getting-started.md) 연습에 제공된 AWS CloudFormation 템플릿을 사용하여 VPC 및 노드 그룹을 생성하면 컨트롤 플레인 및 노드 보안 그룹이 권장 설정으로 구성됩니다. 보안 그룹 고려 사항에 대한 자세한 내용은 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 섹션을 참조하세요. 새 클러스터를 생성할 때 Amazon EKS에서는 클러스터와 통신하는 데 사용하는 관리형 Kubernetes API 서버에 대한 엔드포인트를 생성합니다(`kubectl`과 같은 Kubernetes 관리 도구 사용). 기본적으로 이 API 서버 엔드포인트는 인터넷에 공개되어 있으며, API 서버에 대한 액세스는 AWS Identity and Access Management(IAM) 및 기본 Kubernetes [역할 기반 액세스 제어](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)(RBAC)의 조합을 통해 보호됩니다. 노드와 API 서버 간의 모든 통신이 VPC 내에 유지되도록 Kubernetes API 서버에 대한 프라이빗 액세스를 활성화할 수 있습니다. 인터넷에서 API 서버로 액세스하는 IP 주소를 제한하거나 API 서버로의 인터넷 액세스를 완전히 비활성화할 수 있습니다. 클러스터 엔드포인트 액세스 수정에 대한 자세한 내용은 [클러스터 엔드포인트 액세스 수정](cluster-endpoint.md#modify-endpoint-access) 섹션을 참조하세요. Amazon VPC CNI 또는 [Project Calico](https://docs.tigera.io/calico/latest/about/)와 같은 타사 도구로 Kubernetes *네트워크 정책*을 구현할 수 있습니다. 네트워크 정책에 맞는 Amazon VPC CNI 사용에 관한 자세한 내용은 [Kubernetes 네트워크 정책을 통해 pod 트래픽 제한](cni-network-policy.md) 섹션을 참조하세요. Project Calico는 타사 오픈소스 프로젝트입니다. 자세한 내용은 [Project Calico 설명서](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks/)를 참조하세요. # AWS PrivateLink를 사용하여 Amazon EKS에 액세스 AWS 프라이빗 링크를 사용하여 VPC와 Amazon Elastic Kubernetes Service 사이에 프라이빗 연결을 생성할 수 있습니다. 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect를 사용하지 않고 VPC에 있는 것처럼 Amazon EKS에 액세스할 수 있습니다. VPC의 인스턴스에서 Amazon EKS에 액세스하는 데 퍼블릭 IP 주소가 필요하지 않습니다. AWS 프라이빗 링크에서 제공되는 인터페이스 엔드포인트를 생성하여 이 프라이빗 연결을 설정합니다. 인터페이스 엔드포인트에 대해 사용 설정하는 각 서브넷에서 엔드포인트 네트워크 인터페이스를 생성합니다. 이는 Amazon EKS로 향하는 트래픽의 진입점 역할을 하는 요청자 관리형 네트워크 인터페이스입니다. 자세한 내용은 * AWS PrivateLink 가이드*의 [AWS PrivateLink를 통한 AWS 서비스 액세스](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)를 참조하세요. ## 시작하기 전 준비 사항 시작하기 전에 다음 태스크를 수행했는지 확인합니다. + *AWS PrivateLink 가이드*의 [인터페이스 VPC 엔드포인트를 사용하여 AWS 서비스에 액세스](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) 검토 ## 고려 사항 + **지원 및 제한 사항**: Amazon EKS 인터페이스 엔드포인트를 사용하면 VPC에서 모든 Amazon EKS API 작업에 안전하게 액세스할 수 있지만 특정 제한 사항이 있습니다. 별도의 프라이빗 엔드포인트가 있으므로 Kubernetes API에 대한 액세스를 지원하지 않으며, 인터페이스 엔드포인트를 통해서만 액세스할 수 있도록 Amazon EKS를 구성할 수 없습니다. + **요금**: Amazon EKS에 인터페이스 엔드포인트를 사용하면 표준 AWS PrivateLink 요금이 발생합니다. 즉, 각 가용 영역에 프로비저닝된 각 엔드포인트에 대한 시간당 요금, 엔드포인트를 통과하는 트래픽에 대한 데이터 처리 요금이 발생합니다. 자세히 알아보려면 [AWS PrivateLink 요금](https://aws.amazon.com/privatelink/pricing/)을 참조하세요. + **보안 및 액세스 제어**: VPC 엔드포인트 정책을 사용하여 인터페이스 엔드포인트를 통해 Amazon EKS에 대한 액세스를 제어하고, 보안 그룹을 엔드포인트 네트워크 인터페이스와 연결하여 트래픽을 관리하고, VPC 흐름 로그를 사용하여 인터페이스 엔드포인트와 주고받는 IP 트래픽을 캡처 및 모니터링하고, Amazon CloudWatch 또는 Amazon S3에 로그를 게시하는 등의 추가 구성으로 보안을 강화하고 액세스를 제어하는 것이 좋습니다. 자세한 내용은 [Control access to VPC endpoints using endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)와 [VPC 흐름 로그를 사용하여 IP 트래픽 로깅](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)을 참조하세요. + **연결 옵션**: 인터페이스 엔드포인트는 **온프레미스 액세스**(AWS Direct Connect 또는 AWS Site-to-Site VPN을 사용하여 인터페이스 엔드포인트가 있는 VPC에 온프레미스 데이터 센터 연결) 또는 **VPC 간 연결**(AWS Transit Gateway 또는 VPC 피어링을 사용하여 인터페이스 엔드포인트가 있는 VPC에 다른 VPC 연결 및 AWS 네트워크 내에 트래픽 유지)을 사용하여 유연한 연결 옵션을 제공합니다. + **IP 버전 지원**: 2024년 8월 이전에 생성된 엔드포인트는 eks.region.amazonaws.com을 사용하여 IPv4만 지원합니다. 2024년 8월 이후에 생성된 새 엔드포인트는 이중 스택 IPv4 및 IPv6(예: eks.region.amazonaws.com, eks.region.api.aws)를 지원합니다. + **리전별 가용성**: 아시아 태평양(말레이시아)(ap-southeast-5), 아시아 태평양(태국)(ap-southeast-7), 멕시코(중부)(mx-central-1) 및 아시아 태평양(타이페이)(ap-east-2) 리전에서는 EKS API용 AWS PrivateLink를 사용할 수 없습니다. AWS eks-auth(EKS Pod Identity)에 대한 PrivateLink 지원은 아시아 태평양(말레이시아)(ap-southeast-5) 리전에서 사용할 수 있습니다. ## Amazon EKS용 인터페이스 엔드포인트 생성 Amazon VPC 콘솔 또는 AWS 명령줄 인터페이스(AWS CLI)를 사용하여 Amazon EKS의 인터페이스 엔드포인트를 생성할 수 있습니다. 자세한 정보는 *AWS 프라이빗 링크 가이드*의 [VPC 엔드포인트 생성](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)을 참조하세요. 다음과 같은 서비스 이름을 사용하여 Amazon EKS의 인터페이스 엔드포인트를 생성합니다. ### EKS API + com.amazonaws.region-code.eks + com.amazonaws.region-code.eks-fips(FIPS 준수 엔드포인트용) ### EKS 인증 API(EKS Pod Identity) + com.amazonaws.region-code.eks-auth ## Amazon EKS 인터페이스 엔드포인트를 위한 프라이빗 DNS 기능 Amazon EKS와 기타 AWS 서비스의 인터페이스 엔드포인트에 대해 기본적으로 활성화된 프라이빗 DNS 기능은 기본 리전 DNS 이름을 사용하여 안전한 프라이빗 API 요청을 용이하게 합니다. 이 기능을 사용하면 API 직접 호출이 프라이빗 AWS 네트워크를 통해 인터페이스 엔드포인트로 라우팅되어 보안과 성능이 향상됩니다. Amazon EKS 또는 기타 AWS 서비스에 대한 인터페이스 엔드포인트를 생성하면 프라이빗 DNS 기능이 자동으로 활성화됩니다. 활성화하려면 특정 속성을 설정하여 VPC를 올바르게 구성해야 합니다. + **enableDnsHostnames**: VPC 내의 인스턴스가 DNS 호스트 이름을 가질 수 있도록 허용합니다. + **enableDnsSupport**: VPC 전체에서 DNS 확인을 활성화합니다. 이러한 설정을 확인하거나 수정하는 단계별 지침은 [VPC의 DNS 속성](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)을 참조하세요. ### DNS 이름 및 IP 주소 유형 프라이빗 DNS 기능을 활성화하면 특정 DNS 이름을 사용하여 Amazon EKS에 연결할 수 있으며, 이러한 옵션은 시간이 지남에 따라 발전합니다. + **eks.region.amazonaws.com**: 2024년 8월 전에는 IPv4 주소로만 확인되는 기존 DNS 이름입니다. 이중 스택으로 업데이트된 기존 엔드포인트의 경우 이 이름은 IPv4 주소와 IPv6 주소 모두로 확인됩니다. + **eks.region.api.aws**: 2024년 8월 이후에 생성된 새 엔드포인트에 사용할 수 있는 이 이중 스택 DNS 이름은 IPv4 주소와 IPv6 주소 모두로 확인됩니다. 2024년 8월 이후에는 새 인터페이스 엔드포인트에 2개의 DNS 이름이 제공되며, 이중 스택 IP 주소 유형을 선택할 수 있습니다. 기존 엔드포인트의 경우 이중 스택으로 업데이트하면 IPv4와 IPv6를 모두 지원하도록 **eks.region.amazonaws.com**이 수정됩니다. ### 프라이빗 DNS 기능 사용 구성이 완료되면 프라이빗 DNS 기능을 워크플로에 통합하여 다음과 같은 기능을 제공할 수 있습니다. + **API 요청**: Amazon EKS에 API 요청을 하려면 엔드포인트 설정에 따라 `eks.region.amazonaws.com` 또는 `eks.region.api.aws`와 같은 기본 리전 DNS 이름을 사용합니다. + **애플리케이션 호환성**: EKS API를 직접적으로 호출하는 기존 애플리케이션은 이 기능을 활용하기 위해 변경할 필요가 없습니다. + ** AWS CLI와 이중 스택**: AWS CLI와 함께 이중 스택 엔드포인트를 사용하려면 *AWS SDK 및 도구 참조 가이드*의 [이중 스택 및 FIPS 엔드포인트](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) 구성을 참조하세요. + **자동 라우팅**: Amazon EKS 기본 서비스 엔드포인트에 대한 모든 직접 호출은 자동으로 인터페이스 엔드포인트를 통해 전달되어 안전한 프라이빗 연결이 보장됩니다. # Amazon EKS 클러스터에서 복원력 이해 AWS 글로벌 인프라는 AWS 리전 및 가용 영역을 중심으로 구축됩니다. AWS 리전은 물리적으로 분리되고 격리된 다수의 가용 리전을 제공하며 이러한 가용 리전은 짧은 지연 시간, 높은 처리량 및 높은 중복성을 갖춘 네트워크에 연결되어 있습니다. 가용 영역을 사용하면 중단 없이 가용 영역 간에 자동으로 장애 조치가 이루어지는 애플리케이션 및 데이터베이스를 설계하고 운영할 수 있습니다. 가용 영역은 기존의 단일 또는 복수 데이터 센터 인프라보다 가용성, 내결함성, 확장성이 뛰어납니다. Amazon EKS는 여러 AWS 가용 영역에 걸쳐 Kubernetes 제어 플레인을 실행하고 크기 조정하여 높은 가용성을 보장합니다. Amazon EKS는 로드에 따라 제어 영역 인스턴스의 크기를 자동으로 조정하고, 비정상 제어 영역 인스턴스를 감지하고 교체하며, 자동으로 제어 영역을 패치합니다. 버전 업데이트를 시작하면 Amazon EKS가 제어 영역을 업데이트하여 업데이트 중에 제어 영역의 고가용성을 유지합니다. 이 제어 플레인은 2개 이상의 API 서버 인스턴스와 AWS 리전 내 3개의 가용 영역에서 실행되는 3개의 `etcd` 인스턴스로 구성됩니다. Amazon EKS: + 제어 플레인 인스턴스의 로드를 적극적으로 모니터링하고 자동으로 확장하여 높은 성능을 보장합니다. + 비정상 제어 플레인 인스턴스를 자동으로 감지하고 교체하여 필요에 따라 AWS 리전 내의 가용 영역에서 다시 시작합니다. + AWS 리전의 아키텍처를 활용하여 고가용성을 유지합니다. 따라서 Amazon EKS는 [API 서버 엔드포인트 가용성을 위한 SLA](https://aws.amazon.com/eks/sla)를 제공할 수 있습니다. AWS 리전 및 가용 영역에 대한 자세한 내용은 [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure/)를 참조하세요. # Amazon EKS의 교차 서비스 혼동된 대리자 예방 혼동된 대리자 문제는 작업을 수행할 권한이 없는 엔터티가 권한이 더 많은 엔터티에게 작업을 수행하도록 강요할 수 있는 보안 문제입니다. AWS에서는 교차 서비스 가장으로 인해 혼동된 대리자 문제가 발생할 수 있습니다. 교차 서비스 가장은 한 서비스(*직접 호출하는 서비스*)가 다른 서비스(*직접 호출되는 서비스*)를 직접 호출할 때 발생할 수 있습니다. 직접적으로 호출하는 서비스는 다른 고객의 리소스에 대해 액세스 권한이 없는 방식으로 작동하게 권한을 사용하도록 조작될 수 있습니다. 이를 방지하기 위해 AWS에서는 계정의 리소스에 대한 액세스 권한이 부여된 서비스 위탁자를 사용하여 모든 서비스에 대한 데이터를 보호하는 데 도움이 되는 도구를 제공합니다. Amazon Elastic Kubernetes Service(Amazon EKS)가 리소스에 다른 서비스를 제공하는 권한을 제한하려면 리소스 정책에서 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) 및 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) 글로벌 조건 컨텍스트 키를 사용하는 것이 좋습니다. `aws:SourceArn` `aws:SourceArn`을 사용하면 하나의 리소스만 교차 서비스 액세스 권한과 연결됩니다. `aws:SourceAccount` `aws:SourceAccount`를 사용하면 해당 계정의 모든 리소스가 교차 서비스 사용 권한과 연결됩니다. 혼동된 대리인 문제로부터 보호하는 가장 효과적인 방법은 리소스의 전체 ARN이 포함된 `aws:SourceArn`글로벌 조건 컨텍스트 키를 사용하는 것입니다. 리소스의 전체 ARN을 모르거나 여러 리소스를 지정하는 경우, ARN의 알 수 없는 부분에 대해 와일드카드 문자(\$1)를 포함한 `aws:SourceArn` 글로벌 조건 컨텍스트 키를 사용합니다. 예를 들어 ` arn:aws::*:<123456789012>:*`입니다. 만약 `aws:SourceArn` 값에 Amazon S3 버킷 ARN과 같은 계정 ID가 포함되어 있지 않은 경우, 권한을 제한하려면 두 `aws:SourceAccount` 및 `aws:SourceArn`를 모두 사용해야 합니다. ## Amazon EKS 클러스터 역할 교차 서비스 혼동된 대리자 방지 각 클러스터에는 Amazon EKS 클러스터 IAM 역할이 필요합니다. Amazon EKS에서 관리하는 Kubernetes 클러스터는 이 역할을 사용하여 노드를 관리하고, [레거시 클라우드 제공업체](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)는 이 역할을 사용하여 서비스용 Elastic Load Balancing으로 로드 밸런서를 생성합니다. 이러한 클러스터 작업은 동일한 계정에만 영향을 미칠 수 있으므로 각 클러스터 역할을 해당 클러스터 및 계정으로 제한하는 것이 좋습니다. 이는 계정의 *최소 권한 원칙*을 따르는 AWS 권장 사항을 적용한 것입니다. **소스 ARN 형식** `aws:SourceArn`의 값은 ` arn:aws:eks:region:account:cluster/cluster-name ` 형식의 EKS 클러스터 ARN이어야 합니다. 예: ` arn:aws:eks:us-west-2:123456789012:cluster/my-cluster`. **EKS 클러스터 역할에 대한 신뢰 정책 형식** 다음 예시에서는 Amazon EKS에서 `aws:SourceArn` 및 `aws:SourceAccount` 전역 조건 컨텍스트 키를 사용하여 혼동된 대리자 문제를 방지하는 방법을 보여줍니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-cluster" }, "StringEquals": { "aws:SourceAccount": "123456789012" } } } ] } ``` # Kubernetes의 보안 고려 사항 다음은 Amazon EKS 클러스터에서 Kubernetes에 영향을 미치는 클라우드 보안 고려 사항입니다. Kubernetes의 보안 제어 및 관행에 대한 심층 검토는 Kubernetes Documentation의 [Cloud Native Security and Kubernetes](https://kubernetes.io/docs/concepts/security/cloud-native-security/)를 참조하세요. **Topics** + [Kubernetes 인증서로 워크로드 보안](cert-signing.md) + [Amazon EKS 기반 RBAC 역할 및 사용자 이해](default-roles-users.md) + [기존 클러스터에서 KMS를 사용하여 Kubernetes 비밀 암호화](enable-kms.md) + [Amazon EKS 포드와 함께 AWS Secrets Manager 보안 암호 사용](manage-secrets.md) + [모든 Kubernetes API 데이터에 대한 기본 봉투 암호화](envelope-encryption.md) # Kubernetes 인증서로 워크로드 보안 Kubernetes Certificates API를 통해 [X.509](https://www.itu.int/rec/T-REC-X.509) 자격 증명 프로비저닝이 자동화됩니다. API는 Kubernetes API 클라이언트가 인증 기관(CA)에서 [X.509 인증서](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)를 요청하고 받을 수 있는 명령줄 인터페이스를 제공합니다. 표시된 서명자가 인증서에 서명하도록 요청하는 데 `CertificateSigningRequest`(CSR) 리소스를 사용할 수 있습니다. 요청은 서명되기 전에 승인되거나 거부됩니다. Kubernetes는 잘 정의된 동작을 통해 기본 제공 서명자와 사용자 지정 서명자를 모두 지원합니다. 이렇게 하면 클라이언트는 CSR에 어떤 일이 일어나는지 예측할 수 있습니다. 인증서 서명에 대한 자세한 내용을 알아보려면 [서명 요청](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/)을 참조하세요. 기본 제공 서명자 중 하나는 `kubernetes.io/legacy-unknown`입니다. CSR 리소스의 `v1beta1` API는 이 legacy-unknown 서명자를 준수했습니다. 그러나 CSR의 안정적인 `v1` API에서는 `signerName`이 `kubernetes.io/legacy-unknown`으로 설정되도록 허용하지 않습니다. Amazon EKS CA를 사용하여 클러스터에서 인증서를 생성하려는 경우 사용자 지정 서명자를 사용해야 합니다. CSR `v1` API 버전을 사용하여 새 인증서를 생성하려면 기존 매니페스트 및 API 클라이언트를 마이그레이션해야 합니다. 기존 `v1beta1` API를 사용하여 생성된 기존 인증서는 유효하며 인증서가 만료될 때까지 기능합니다. 다음 내용이 포함됩니다: + 신뢰 배포: 없음. Kubernetes 클러스터에는 이 서명자에 대한 표준 트러스트나 배포가 없습니다. + 허용된 과목: 모두 + 허용된 x509 확장 기능: subjectAltName 및 키 사용 확장 기능을 준수하고 다른 확장 기능을 폐기합니다. + 허용된 키 사용: ["키 암호화”, “디지털 서명”, “서버 인증"] 이외의 용도는 포함하지 않아야 합니다. **참고** 클라이언트 인증서 서명은 지원되지 않습니다. + 만료/인증서 수명: 1년(기본 및 최대) + CA 비트 허용됨/허용되지 않음: 허용되지 않음 ## signerName을 사용한 CSR 생성 예 다음 단계에서는 `signerName: beta.eks.amazonaws.com/app-serving`을 사용하여 `myserver.default.svc` DNS 이름에 대한 서빙 인증서를 생성하는 방법을 보여줍니다. 이 정보를 사용자 환경에 대한 가이드로 사용합니다. 1. `openssl genrsa -out myserver.key 2048` 명령을 실행하여 RSA 프라이빗 키를 생성합니다. ``` openssl genrsa -out myserver.key 2048 ``` 1. 다음 명령을 실행하여 인증 요청을 생성합니다. ``` openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc" ``` 1. CSR 요청에 대한 `base64` 값을 생성하고 이후 단계에서 사용할 수 있도록 변수에 저장합니다. ``` base_64=$(cat myserver.csr | base64 -w 0 | tr -d " ") ``` 1. 다음 명령을 실행하여 `mycsr.yaml`이라는 파일을 생성합니다. 다음 예에서 `beta.eks.amazonaws.com/app-serving`은 `signerName`입니다. ``` cat >mycsr.yaml < myserver.crt ``` # Amazon EKS 기반 RBAC 역할 및 사용자 이해 Kubernetes 클러스터를 생성하면 Kubernetes가 제대로 작동하도록 해당 클러스터에 여러 개의 기본 Kubernetes ID가 생성됩니다. Amazon EKS는 각 기본 구성 요소에 대한 Kubernetes ID를 생성합니다. ID에서는 클러스터 구성 요소에 대한 Kubernetes RBAC(역할 기반 권한 부여 제어)가 제공됩니다. 자세한 내용은 Kubernetes 문서의 [Using RBAC Authorization(RBAC 승인 사용)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)을 참조하세요. 클러스터에 선택적 [추가 기능](eks-add-ons.md)을 설치하면 클러스터에 추가 Kubernetes ID가 추가될 수도 있습니다. 이 주제에서 다루지 않는 자격 증명에 대한 자세한 내용은 추가 기능에 대한 설명서를 참조하세요. Amazon EKS에서 클러스터에 생성한 Kubernetes ID 목록은 AWS Management Console 또는 `kubectl` 명령줄 도구를 사용하여 볼 수 있습니다. 모든 사용자 자격 증명은 Amazon CloudWatch를 통해 사용할 수 있는 `kube` 감사 로그에 표시됩니다. ## AWS Management Console ### 사전 조건 사용하는 [IAM 위탁자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)는 [필수 권한](view-kubernetes-resources.md#view-kubernetes-resources-permissions)에 설명된 권한을 가지고 있어야 합니다. ### AWS Management Console을 사용하여 Amazon EKS에서 생성한 자격 증명을 보는 방법 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 보려는 자격 증명이 포함된 클러스터를 **클러스터** 목록에서 선택합니다. 1. **리소스** 탭을 선택합니다. 1. **리소스 유형**에서 **권한 부여**를 선택합니다. 1. **ClusterRoles**, **ClusterRoleBindings**, **Roles** 또는 **RoleBindings**를 선택합니다. 앞에 **eks**로 시작하는 모든 리소스는 Amazon EKS에서 생성합니다. Amazon EKS에서 생성한 추가 자격 증명 리소스는 다음과 같습니다. + **ClusterRole** 및 **aws-node**라는 **ClusterRoleBinding**. **aws-node** 리소스에서는 Amazon EKS에서 모든 클러스터에 설치하는 [Kubernetes용 Amazon VPC CNI 플러그인](managing-vpc-cni.md)을 지원합니다. + **vpc-resource-controller-role**이라는 **ClusterRole** 및 **vpc-resource-controller-rolebinding**이라는 **ClusterRoleBinding**. 이러한 리소스에서는 Amazon EKS에서 모든 클러스터에 설치하는 [Amazon VPC 리소스 컨트롤러](https://github.com/aws/amazon-vpc-resource-controller-k8s)를 지원합니다. 콘솔에 표시되는 리소스 외에 다음과 같은 특별한 사용자 자격 증명이 클러스터에 있지만, 클러스터의 구성에는 표시되지 않습니다. + ** `eks:cluster-bootstrap` **– 클러스터 부트스트랩 중 `kubectl` 작업에 사용됩니다. + **`eks:support-engineer`** – 클러스터 관리 작업에 사용됩니다. 1. 특정 리소스를 선택하면 해당 세부 정보를 볼 수 있습니다. 기본적으로 **구조화된 뷰**에 정보가 표시됩니다. 세부 정보 페이지의 오른쪽 상단에서 **Raw view**(원시 뷰)를 선택하여 리소스에 대한 모든 정보를 볼 수 있습니다. ## kubectl ### 사전 조건 클러스터에 Kubernetes 리소스를 나열하는 데 사용하는 엔터티(AWS Identity and Access Management(IAM) 또는 OpenID Connect (OIDC))는 IAM 또는 OIDC ID 제공업체에 의해 인증되어야 합니다. 엔터티를 연동하려는 클러스터의 `Role`, `ClusterRole`, `RoleBinding`및 `ClusterRoleBinding` 리소스에 `get` Kubernetes 및 `list` 동사를 사용하는 권한이 엔터티에 부여되어야 합니다. IAM 엔터티에 클러스터 액세스 권한을 부여하는 자세한 내용은 [IAM 사용자 및 역할에 Kubernetes API에 대한 액세스 권한 부여](grant-k8s-access.md) 섹션을 참조하세요. 자체 OIDC 제공자에서 인증한 엔터티에 클러스터 액세스 권한을 부여하는 것에 대한 자세한 내용은 [외부 OIDC 제공자를 통해 사용자에게 Kubernetes에 대한 액세스 권한 부여](authenticate-oidc-identity-provider.md) 섹션을 참조하세요. ### `kubectl`을 사용하여 Amazon EKS에서 생성한 자격 증명을 보는 방법 표시하려는 리소스 유형에 대한 명령을 실행합니다. **eks**로 시작하는 반환된 모든 리소스는 Amazon EKS에서 생성합니다. 출력에서 반환되는 리소스 외에 다음과 같은 특별한 사용자 자격 증명이 클러스터에 있지만, 클러스터의 구성에는 표시되지 않습니다. + ** `eks:cluster-bootstrap` **– 클러스터 부트스트랩 중 `kubectl` 작업에 사용됩니다. + **`eks:support-engineer`** – 클러스터 관리 작업에 사용됩니다. **ClusterRoles** – `ClusterRoles`의 범위가 클러스터로 지정되므로 역할에 부여된 모든 권한이 클러스터의 모든 Kubernetes 네임스페이스에 있는 리소스에 적용됩니다. 다음 명령은 클러스터의 Amazon EKS 생성 Kubernetes `ClusterRoles`을 모두 반환합니다. ``` kubectl get clusterroles | grep eks ``` 출력에서 반환되어 앞에 붙는 `ClusterRoles` 외에 다음과 같은 `ClusterRoles`가 있습니다. + **`aws-node`** - 이 `ClusterRole`에서는 Amazon EKS가 모든 클러스터에 설치하는 [Kubernetes용 Amazon VPC CNI 플러그인](managing-vpc-cni.md)을 지원합니다. + ** `vpc-resource-controller-role` **– 이 `ClusterRole`에서는 Amazon EKS에서 모든 클러스터에 설치하는 [Amazon VPC 리소스 컨트롤러](https://github.com/aws/amazon-vpc-resource-controller-k8s)를 지원합니다. `ClusterRole`의 사양을 표시하려면 다음과 같은 명령의 *eks:k8s-metrics*를 이전 명령의 출력에서 반환된 `ClusterRole`로 바꿉니다. 다음 예시에서는 *eks:k8s-metrics* `ClusterRole`에 대한 사양을 반환합니다. ``` kubectl describe clusterrole eks:k8s-metrics ``` 예제 출력은 다음과 같습니다. ``` Name: eks:k8s-metrics Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- [/metrics] [] [get] endpoints [] [] [list] nodes [] [] [list] pods [] [] [list] deployments.apps [] [] [list] ``` **ClusterRoleBindings** – `ClusterRoleBindings`의 범위가 클러스터로 지정됩니다. 다음 명령은 클러스터의 Amazon EKS 생성 Kubernetes `ClusterRoleBindings`을 모두 반환합니다. ``` kubectl get clusterrolebindings | grep eks ``` 출력에서 반환된 `ClusterRoleBindings` 외에 다음과 같은 `ClusterRoleBindings`가 있습니다. + **`aws-node`** - 이 `ClusterRoleBinding`에서는 Amazon EKS가 모든 클러스터에 설치하는 [Kubernetes용 Amazon VPC CNI 플러그인](managing-vpc-cni.md)을 지원합니다. + ** `vpc-resource-controller-rolebinding` **– 이 `ClusterRoleBinding`에서는 Amazon EKS에서 모든 클러스터에 설치하는 [Amazon VPC 리소스 컨트롤러](https://github.com/aws/amazon-vpc-resource-controller-k8s)를 지원합니다. `ClusterRoleBinding`의 사양을 표시하려면 다음과 같은 명령의 *eks:k8s-metrics*를 이전 명령의 출력에서 반환된 `ClusterRoleBinding`로 바꿉니다. 다음 예시에서는 *eks:k8s-metrics* `ClusterRoleBinding`에 대한 사양을 반환합니다. ``` kubectl describe clusterrolebinding eks:k8s-metrics ``` 예제 출력은 다음과 같습니다. ``` Name: eks:k8s-metrics Labels: Annotations: Role: Kind: ClusterRole Name: eks:k8s-metrics Subjects: Kind Name Namespace ---- ---- --------- User eks:k8s-metrics ``` **Roles** – `Roles`의 범위가 Kubernetes 네임스페이스로 지정됩니다. Amazon EKS에서 생성한 모든 `Roles`의 범위가 `kube-system` 네임스페이스로 지정됩니다. 다음 명령은 클러스터의 Amazon EKS 생성 Kubernetes `Roles`을 모두 반환합니다. ``` kubectl get roles -n kube-system | grep eks ``` `Role`의 사양을 표시하려면 다음과 같은 명령의 *eks:k8s-metrics*를 이전 명령의 출력에서 반환된 `Role`의 이름으로 변경합니다. 다음 예시에서는 *eks:k8s-metrics* `Role`에 대한 사양을 반환합니다. ``` kubectl describe role eks:k8s-metrics -n kube-system ``` 예제 출력은 다음과 같습니다. ``` Name: eks:k8s-metrics Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- daemonsets.apps [] [aws-node] [get] deployments.apps [] [vpc-resource-controller] [get] ``` **RoleBindings** – `RoleBindings`의 범위가 Kubernetes 네임스페이스로 지정됩니다. Amazon EKS에서 생성한 모든 `RoleBindings`의 범위가 `kube-system` 네임스페이스로 지정됩니다. 다음 명령은 클러스터의 Amazon EKS 생성 Kubernetes `RoleBindings`을 모두 반환합니다. ``` kubectl get rolebindings -n kube-system | grep eks ``` `RoleBinding`의 사양을 표시하려면 다음과 같은 명령의 *eks:k8s-metrics*를 이전 명령의 출력에서 반환된 `RoleBinding`로 바꿉니다. 다음 예시에서는 *eks:k8s-metrics* `RoleBinding`에 대한 사양을 반환합니다. ``` kubectl describe rolebinding eks:k8s-metrics -n kube-system ``` 예제 출력은 다음과 같습니다. ``` Name: eks:k8s-metrics Labels: Annotations: Role: Kind: Role Name: eks:k8s-metrics Subjects: Kind Name Namespace ---- ---- --------- User eks:k8s-metrics ``` # 기존 클러스터에서 KMS를 사용하여 Kubernetes 비밀 암호화 **중요** 이 절차는 Kubernetes 버전 1.27 이하가 실행되는 EKS 클러스터에만 적용됩니다. Kubernetes 버전 1.28 이상을 실행하는 경우 Kubernetes 비밀은 기본적으로 봉투 암호화로 보호됩니다. 자세한 내용은 [모든 Kubernetes API 데이터에 대한 기본 봉투 암호화](envelope-encryption.md) 섹션을 참조하세요. [비밀 암호화](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)를 사용 설정하는 경우 Kubernetes 비밀은 선택한 AWS KMS 키를 사용하여 암호화됩니다. KMS 키는 다음 조건을 충족해야 합니다. + 대칭 + 데이터 암호화 및 해독 가능 + 클러스터와 같은 AWS 리전에 생성됨 + KMS 키가 다른 계정에서 생성된 경우 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)는 KMS 키에 액세스할 수 있어야 합니다. 자세한 내용은 * [AWS 키 관리 서비스 개발자 가이드](https://docs.aws.amazon.com/kms/latest/developerguide/)*에서 [다른 계정의 IAM 주체가 KMS 키를 사용하도록 허용하기](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html)를 참조하세요. **주의** 비밀 암호화를 사용 설정한 후에는 사용 중지할 수 없습니다. 이 작업은 되돌릴 수 없습니다. eksctl 이 절차는 Kubernetes 버전 1.27 이하가 실행되는 EKS 클러스터에만 적용됩니다. 자세한 내용은 [모든 Kubernetes API 데이터에 대한 기본 봉투 암호화](envelope-encryption.md) 섹션을 참조하세요. 다음 두 가지 방법으로 암호화를 활성화할 수 있습니다. + 단일 명령으로 클러스터에 암호화를 추가합니다. 비밀을 자동으로 다시 암호화하려면 다음 명령을 실행합니다. ``` eksctl utils enable-secrets-encryption \ --cluster my-cluster \ --key-arn arn:aws:kms:region-code:account:key/key ``` 비밀을 자동으로 다시 암호화하는 것을 옵트아웃하려면 다음 명령을 실행합니다. ``` eksctl utils enable-secrets-encryption --cluster my-cluster \ --key-arn arn:aws:kms:region-code:account:key/key \ --encrypt-existing-secrets=false ``` + `kms-cluster.yaml` 파일을 사용하여 클러스터에 암호화를 추가합니다. ``` apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: region-code secretsEncryption: keyARN: arn:aws:kms:region-code:account:key/key ``` 비밀을 자동으로 다시 암호화하려면 다음 명령을 실행합니다. ``` eksctl utils enable-secrets-encryption -f kms-cluster.yaml ``` 비밀을 자동으로 다시 암호화하는 것을 옵트아웃하려면 다음 명령을 실행합니다. ``` eksctl utils enable-secrets-encryption -f kms-cluster.yaml --encrypt-existing-secrets=false ``` AWS Management Console 1. 이 절차는 Kubernetes 버전 1.27 이하가 실행되는 EKS 클러스터에만 적용됩니다. 자세한 내용은 [모든 Kubernetes API 데이터에 대한 기본 봉투 암호화](envelope-encryption.md) 섹션을 참조하세요. 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. KMS 암호화를 추가하려는 클러스터를 선택합니다. 1. **개요** 탭을 선택합니다(기본적으로 선택되어 있음). 1. 아래로 스크롤하여 **비밀 암호화** 섹션으로 이동하고 **활성화**를 선택합니다. 1. 드롭다운 목록에서 키를 선택하고 **활성화** 버튼을 선택합니다. 나열된 키가 없으면 먼저 키를 생성해야 합니다. 자세한 내용은 [키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)을 참조하세요. 1. **확인** 버튼을 선택하고 선택한 키를 사용합니다. AWS CLI 1. 이 절차는 Kubernetes 버전 1.27 이하가 실행되는 EKS 클러스터에만 적용됩니다. 자세한 내용은 [모든 Kubernetes API 데이터에 대한 기본 봉투 암호화](envelope-encryption.md) 섹션을 참조하세요. 1. 다음 AWS CLI 명령을 사용하여 [비밀 암호화](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) 구성을 클러스터와 연결합니다. 예제 값을 사용자의 값으로 바꿉니다. ``` aws eks associate-encryption-config \ --cluster-name my-cluster \ --encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"arn:aws:kms:region-code:account:key/key"}}]' ``` 예제 출력은 다음과 같습니다. ``` {   "update": {     "id": "3141b835-8103-423a-8e68-12c2521ffa4d",     "status": "InProgress",     "type": "AssociateEncryptionConfig",     "params": [       {         "type": "EncryptionConfig",         "value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:region-code:account:key/key\"}}]"       }     ],     "createdAt": 1613754188.734,     "errors": []   } } ``` 1. 다음 명령을 사용하여 암호화 업데이트의 상태를 모니터링할 수 있습니다. 이전 출력에서 반환된 특정 `cluster name` 및 `update ID`를 사용합니다. `Successful` 상태가 표시되면 업데이트가 완료됩니다. ``` aws eks describe-update \ --region region-code \ --name my-cluster \ --update-id 3141b835-8103-423a-8e68-12c2521ffa4d ``` 예제 출력은 다음과 같습니다. ``` {   "update": {     "id": "3141b835-8103-423a-8e68-12c2521ffa4d",     "status": "Successful",     "type": "AssociateEncryptionConfig",     "params": [       {         "type": "EncryptionConfig",         "value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:region-code:account:key/key\"}}]"       }     ],     "createdAt": 1613754188.734>,     "errors": []   } } ``` 1. 클러스터에서 암호화가 활성화되었는지 확인하려면 `describe-cluster` 명령를 실행합니다. 응답에는 `EncryptionConfig` 문자열이 포함됩니다. ``` aws eks describe-cluster --region region-code --name my-cluster ``` 클러스터에서 암호화를 사용 설정한 후에는 기존 비밀을 모두 새 키로 암호화해야 합니다. **참고** `eksctl`을 사용하면 비밀을 자동으로 다시 암호화하는 것을 옵트아웃하는 경우에만 다음 명령을 실행해야 합니다. ``` kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="time value" ``` **주의** 기존 클러스터에 대해 [비밀 암호화](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)를 사용 설정하고 사용하는 KMS 키가 삭제된 경우에는 클러스터 복구 경로가 없습니다. KMS 키를 삭제하면 클러스터가 영구적으로 성능 저하 상태가 됩니다. 자세한 내용은 [AWS KMS 키](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html)를 참조하세요. **참고** 기본적으로 `create-key` 명령은 AWS KMS 작업 및 리소스에 대한 액세스 권한을 계정 루트 관리자에게 부여하는 키 정책으로 [대칭 암호화 KMS 키](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html)를 생성합니다. 권한을 축소하려면 `create-cluster` API를 직접 호출할 보안 주체의 정책에서 `kms:DescribeKey` 및 `kms:CreateGrant` 작업이 허용되는지 확인합니다. KMS 봉투 암호화를 사용하는 클러스터의 경우 `kms:CreateGrant` 권한이 필요합니다. 조건 `kms:GrantIsForAWSResource`는 CreateCluster 작업에 대해 지원되지 않으며, CreateCluster를 수행하는 사용자에 대한 `kms:CreateGrant` 권한을 제어하기 위해 KMS 정책을 사용해서는 안 됩니다. # Amazon EKS 포드와 함께 AWS Secrets Manager 보안 암호 사용 Secrets Manager의 보안 암호 및 파라미터 스토어의 파라미터를 Amazon EKS 포드에 탑재된 파일로 표시하려면 [Kubernetes 보안 암호 스토어 CSI 드라이버](https://secrets-store-csi-driver.sigs.k8s.io/)에 대한 AWS 보안 암호 및 구성 제공업체(ASCP)를 사용할 수 있습니다. ASCP를 사용하면 Secrets Manager 보안 암호를 저장 및 관리한 후 Amazon EKS에서 실행되는 워크로드를 통해 해당 검색할 수 있습니다. IAM 역할 및 정책을 사용하여 보안 암호에 대한 액세스 권한을 클러스터의 특정 Kubernetes 포드로 제한할 수 있습니다. ASCP는 Pod Identity를 검색하고 IAM 역할에 대한 ID를 교환합니다. ASCP는 포드의 IAM 역할을 가정한 후 해당 역할에 대해 인증된 Secrets Manager에서 보안 암호를 검색할 수 있습니다. 보안 암호에 대해 Secrets Manager 자동 교체를 사용하는 경우 보안 암호 스토어 CSI 드라이버 교체 조정자 기능을 사용하여 Secrets Manager에서 최신 보안 암호를 검색할 수도 있습니다. **참고** AWS Fargate(Fargate) 노드 그룹은 지원되지 않습니다. 자세한 내용은 AWS Secrets Manager 사용 설명서의 [Amazon EKS에서 Secrets Manager 보안 암호 사용](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html)을 참조하세요. # 모든 Kubernetes API 데이터에 대한 기본 봉투 암호화 Amazon Elastic Kubernetes Service(Amazon EKS)는 Kubernetes 버전 1.28 이상을 실행하는 EKS 클러스터의 모든 Kubernetes API 데이터에 기본 봉투 암호화를 제공합니다. 봉투 암호화는 Kubernetes API 서버에 저장하는 데이터를 보호합니다. 예를 들어, 봉투 암호화는 `ConfigMaps`와 같은 Kubernetes 클러스터의 구성에 적용됩니다. 노드 또는 EBS 볼륨의 데이터에는 봉투 암호화가 적용되지 않습니다. EKS에서는 이전에 Kubernetes 비밀 암호화를 지원했으며, 이제 이 봉투 암호화는 모든 Kubernetes API 데이터로 확장됩니다. 이를 통해 Kubernetes 애플리케이션에 심층 방어를 구현하고 사용자 측에서 별도의 조치가 필요하지 않은 관리형 기본 환경을 제공합니다. Amazon EKS는 [Amazon Web Services 소유 키](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)를 사용하는 이 추가 보안 계층을 위해 [Kubernetes KMS 공급자 v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#configuring-the-kms-provider-kms-v2)에 AWS [Key Management Service(KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)를 사용하고, AWS KMS에서 자체 [고객 관리형 키](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)(CMK)를 가져올 수 있는 옵션을 사용합니다. ## 봉투 암호화 이해 봉투 암호화는 데이터 암호화 키(DEK)를 사용하여 일반 텍스트 데이터를 데이터 스토어(etcd)로 전송하기 전에 암호화한 다음, 원격 중앙 관리형 KMS 시스템(AWS KMS)에 저장된 루트 KMS 키로 DEK를 암호화하는 프로세스입니다. 이는 암호화 키(DEK)로 데이터를 보호한 다음 키 암호화 키(KEK)라고 하는 별도의 안전하게 저장된 암호화 키로 해당 DEK를 보호하여 보안 계층을 더하는 심층 방어 전략입니다. ## Amazon EKS가 KMS v2 및 AWS KMS를 사용하여 기본 봉투 암호화를 활성화하는 방법 Amazon EKS는 [KMS v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#kms-v2)를 사용하여 관리형 Kubernetes 컨트롤 플레인의 모든 API 데이터가 [etcd](https://etcd.io/docs/v3.5/faq/) 데이터베이스에 유지되기 전에 기본 봉투 암호화를 구현합니다. 시작 시 클러스터 API 서버는 임의로 생성된 데이터와 결합된 보안 암호 시드로부터 데이터 암호화 키(DEK)를 생성합니다. 또한 시작 시 API 서버는 KMS 플러그인을 직접적으로 호출하여 AWS KMS의 원격 키 암호화 키(KEK)를 사용하여 DEK 시드를 암호화합니다. 이는 API 서버 시작 및 KEK 교체 시 실행되는 일회성 직접 호출입니다. 이후 API 서버는 암호화된 DEK 시드를 캐싱합니다. 그런 다음 API 서버는 캐싱된 DEK 시드를 사용하여 키 파생 함수(KDF)를 기반으로 다른 일회용 DEK를 생성합니다. 생성된 각 DEK는 etcd에 저장되기 전에 단일 Kubernetes 리소스를 암호화하는 데 한 번만 사용됩니다. KMS v2에서 암호화된 캐싱된 DEK 시드를 사용하면 API 서버에서 Kubernetes 리소스를 암호화하는 프로세스의 성능과 비용 효율성이 개선됩니다. **기본적으로이 KEK는 AWS에서 소유하지만 선택적으로 AWS KMS에서 직접 가져올 수 있습니다.** 아래 다이어그램은 API 서버를 시작할 때 DEK의 생성 및 암호화를 보여줍니다. ![\[이 다이어그램은 API 서버를 시작할 때 DEK의 생성 및 암호화를 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/security-generate-dek.png) 아래의 개략적인 다이어그램은 Kubernetes 리소스가 etcd에 저장되기 전에 해당 리소스의 암호화를 보여줍니다. ![\[이 개략적인 다이어그램은 Kubernetes 리소스가 etcd에 저장되기 전에 해당 리소스의 암호화를 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/security-encrypt-request.png) ## 자주 묻는 질문(FAQ) ### 기본 봉투 암호화는 EKS 클러스터의 보안 태세를 어떻게 개선하나요? 이 기능은 메타데이터와 고객 콘텐츠가 암호화되지 않은 표면적과 기간을 줄입니다. 기본 봉투 암호화를 사용하면 메타데이터와 고객 콘텐츠가 etcd에 저장되기 전에 kube-apiserver의 메모리에서 일시적으로 암호화되지 않은 상태에 불과합니다. kube-apiserver의 메모리는 [Nitro 시스템](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-components-of-the-nitro-system.html)을 통해 보호됩니다. Amazon EKS는 관리형 Kubernetes 컨트롤 플레인에 [Nitro 기반 EC2 인스턴스](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html)만 사용합니다. 이러한 인스턴스에는 시스템이나 사용자가 메모리에 액세스하지 못하도록 하는 보안 제어 설계가 마련되어 있습니다. ### 이 기능을 사용하려면 어떤 버전의 Kubernetes를 실행해야 하나요? 기본 봉투 암호화를 활성화하려면 Amazon EKS 클러스터에서 Kubernetes 버전 1.28 이상을 실행해야 합니다. ### 이 기능을 지원하지 않는 Kubernetes 클러스터 버전을 실행하는 경우에도 데이터는 여전히 보호되나요? 예. AWS에서 [가장 우선순위가 높은 것은 보안](https://aws.amazon.com/security/)입니다. 모든 디지털 트랜스포메이션과 혁신을 가장 높은 수준의 보안 운영 관행의 기반으로 하고, 이러한 기준을 높이기 위해 최선을 다합니다. etcd에 저장된 모든 데이터는 실행 중인 Kubernetes 버전과 무관하게 모든 EKS 클러스터의 디스크 수준에서 암호화됩니다. EKS는 EKS 서비스에서 관리하는 볼륨 암호화 키를 생성하는 루트 키를 사용합니다. 추가로 모든 Amazon EKS 클러스터는 클러스터별 가상 머신을 사용하여 격리된 VPC에서 실행됩니다. 이 아키텍처와 운영 보안에 대한 관행으로 인해 Amazon EKS는 SOC 1,2,3, PCI-DSS, ISO 및 HIPAA 자격을 포함하여 [여러 규정 준수 등급 및 표준을 달성](https://docs.aws.amazon.com/eks/latest/userguide/compliance.html)했습니다. 이러한 규정 준수 등급 및 표준은 기본 봉투 암호화가 활성화 또는 활성화되지 않은 모든 EKS 클러스터에 대해 유지됩니다. ### Amazon EKS에서 봉투 암호화는 어떻게 작동하나요? 시작 시 클러스터 API 서버는 임의로 생성된 데이터와 결합된 보안 암호 시드로부터 데이터 암호화 키(DEK)를 생성합니다. 또한 시작 시 API 서버는 KMS 플러그인을 직접 호출하여 AWS KMS의 원격 키 암호화 키(KEK)를 사용하여 DEK를 암호화합니다. 이는 API 서버 시작 및 KEK 교체 시 실행되는 일회성 직접 호출입니다. 이후 API 서버는 암호화된 DEK 시드를 캐싱합니다. 그런 다음 API 서버는 캐싱된 DEK 시드를 사용하여 키 파생 함수(KDF)를 기반으로 다른 일회용 DEK를 생성합니다. 생성된 각 DEK는 etcd에 저장되기 전에 단일 Kubernetes 리소스를 암호화하는 데 한 번만 사용됩니다. AWS KMS 통합의 상태와 정상 기능을 확인하기 위해 API 서버에서 추가로 직접 호출하는 것이 중요합니다. 이러한 추가 상태 확인은 AWS CloudTrail에 표시됩니다. ### 이 기능이 EKS 클러스터에서 작동하려면 어떤 작업을 하거나 어떤 권한을 변경해야 하나요? 아니요, 별도의 조치를 할 필요는 없습니다. Amazon EKS의 봉투 암호화는 이제 Kubernetes 버전 1.28 이상을 실행하는 모든 클러스터에서 활성화된 기본 구성입니다. AWS KMS 통합은 AWS에서 관리하는 Kubernetes API 서버에 의해 설정됩니다. 즉, 클러스터에 KMS 암호화 사용을 시작하기 위해 권한을 구성할 필요가 없습니다. ### 클러스터에서 기본 봉투 암호화가 활성화되어 있는지 어떻게 알 수 있나요? 자체 CMK를 사용하도록 마이그레이션하면 클러스터와 연결된 KMS 키의 ARN이 표시됩니다. 추가로 클러스터의 CMK 사용과 관련된 AWS CloudTrail 이벤트 로그를 볼 수 있습니다. 클러스터가 AWS 소유 키를 사용하는 경우 EKS 콘솔에서 자세히 설명합니다(키의 ARN 제외). ### AWS가 Amazon EKS에서 기본 봉투 암호화에 사용되는 AWS 소유 키에 액세스할 수 있나요? 아니요. AWS의 Amazon EKS의 엄격한 보안 제어 기능이 있어 모든 사용자가 etcd 데이터베이스의 데이터를 보호하는 데 사용되는 일반 텍스트 암호화 키에 액세스하지 못하도록 합니다. 이러한 보안 조치는 AWS 소유 KMS 키에도 적용됩니다. ### 기존 EKS 클러스터에서 기본 봉투 암호화가 활성화되나요? Kubernetes 버전 1.28 이상에서 Amazon EKS 클러스터를 실행하는 경우 모든 Kubernetes API 데이터의 봉투 암호화가 활성화됩니다. 기존 클러스터의 경우 Amazon EKS는 `eks:kms-storage-migrator` RBAC ClusterRole을 사용하여 이전에 etcd에서 봉투 암호화되지 않은 데이터를 이 새 암호화 상태로 마이그레이션합니다. ### EKS 클러스터에서 비밀에 대한 봉투 암호화를 이미 활성화한 경우 이는 무엇을 의미하나요? Kubernetes 비밀을 봉투 암호화하는 데 사용된 KMS의 기존 고객 관리형 키(CMK)가 있는 경우 클러스터의 모든 Kubernetes API 데이터 유형의 봉투 암호화를 위한 KEK로 동일한 키가 사용됩니다. ### 기본 봉투 암호화를 사용하여 EKS 클러스터를 실행하는 데 추가 비용이 발생하나요? 기본 봉투 암호화에 [Amazon Web Services 소유 키](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)를 사용하는 경우 관리형 Kubernetes 컨트롤 플레인과 관련된 추가 비용이 없습니다. 기본적으로 Kubernetes 버전 1.28 이상을 실행하는 모든 EKS 클러스터는 [Amazon Web Service 소유 키](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)를 사용합니다. 하지만 자체 AWS KMS 키를 사용하는 경우 일반 [KMS 요금](https://aws.amazon.com/kms/pricing/)이 적용됩니다. ### 자체 AWS KMS 키를 사용하여 클러스터의 Kubernetes API 데이터를 암호화하는 데 드는 비용은 얼마인가요? 생성하거나 KMS로 가져오는 사용자 지정 키를 저장하기 위해 매월 1 USD를 지불합니다. KMS는 암호화 및 복호화 요청에 대해 요금을 부과합니다. 계정당 매달 20,000개의 요청으로 구성된 프리 티어가 있으며, 사용자는 매달 프리 티어를 초과하는 요청 10,000개당 0.03 USD를 지불합니다. 이는 계정의 모든 KMS 사용량에 적용되므로 클러스터에서 자체 AWS KMS 키를 사용하는 비용은 계정 내 다른 클러스터 또는 AWS 리소스에서 이 키를 사용하는 데 영향을 받습니다. ### 이제 고객 관리형 키(CMK)가 비밀뿐만 아니라 모든 Kubernetes API 데이터를 봉투 암호화하는 데 사용되므로 KMS 요금이 증가하나요? 아니요. KMS v2를 사용하여 구현하면 AWS KMS에 대한 직접 호출 수가 크게 감소합니다. 그러면 EKS 클러스터에서 암호화 또는 복호화되는 추가 Kubernetes 데이터와 무관하게 CMK와 관련된 비용이 절감됩니다. 위에서 자세히 설명한 대로 Kubernetes 리소스의 암호화에 사용되는 생성된 DEK 시드는 원격 KEK로 암호화된 후 Kubernetes API 서버의 캐시에 로컬로 저장됩니다. 암호화된 DEK 시드가 API 서버의 캐시에 없는 경우 API 서버는 AWS KMS를 직접 호출하여 DEK 시드를 암호화합니다. 이후 API 서버는 KMS를 직접 호출하지 않고 클러스터에서 나중에 사용할 수 있도록 암호화된 DEK 시드를 캐싱합니다. 마찬가지로 복호화 요청의 경우 API 서버는 첫 번째 복호화 요청을 위해 AWS KMS를 직접적으로 호출하고, 이후에는 복호화된 DEK 시드가 캐싱되어 향후 복호화 작업에 사용됩니다. 자세한 내용은 GitHub의 Kubernetes 개선 사항에서 [KEP-3299: KMS v2 개선 사항](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3299-kms-v2-improvements)을 참조하세요. ### 여러 개의 Amazon EKS 클러스터에 동일한 CMK 키를 사용할 수 있나요? 예. 키를 다시 사용하려면 생성 중에 ARN을 클러스터와 연결하여 동일한 리전의 클러스터에 연결할 수 있습니다. 하지만 여러 EKS 클러스터에 동일한 CMK를 사용하는 경우 CMK의 임의 비활성화를 방지하기 위해 필요한 조치를 취해야 합니다. 그렇지 않으면 여러 EKS 클러스터와 연결된 비활성화된 CMK는 해당 키에 따라 클러스터에 더 광범위한 영향을 미칩니다. ### 기본 봉투 암호화가 활성화된 후 CMK를 사용할 수 없게 되면 EKS 클러스터는 어떻게 되나요? KMS 키를 비활성화하면 다시 활성화할 때까지 어떠한 [암호화 작업](https://docs.aws.amazon.com/kms/latest/developerguide/kms-cryptography.html#cryptographic-operations)에서도 사용할 수 없습니다. 기존 CMK에 액세스하지 않은 상태에서 API 서버는 새로 생성된 Kubernetes 객체를 암호화 및 유지하는 것은 물론 앞서 암호화되어 etcd에서 저장된 Kubernetes 객체를 복호화할 수 없습니다. CMK가 비활성화된 경우 클러스터는 즉시 비정상/저하 상태로 전환되고, 이때 연결된 CMK를 다시 활성화할 때까지 [서비스 약정](https://aws.amazon.com/eks/sla/)을 이행할 수 없습니다. CMK가 비활성화되면 EKS 클러스터가 저하된 상태이며 Kubernetes 컨트롤 플레인 리소스를 성공적으로 복원하기 위해 비활성화한 후 30일 이내에 CMK를 다시 활성화해야 한다는 알림을 받게 됩니다. ### 비활성화/삭제된 CMK의 영향으로부터 EKS 클러스터를 보호하려면 어떻게 해야 하나요? 이러한 문제로부터 EKS 클러스터를 보호하기 위해 키 관리자는 최소 권한 원칙이 있는 IAM 정책을 사용하여 KMS 키 작업에 대한 액세스를 관리하여 EKS 클러스터와 연결된 키의 임의 비활성화 또는 삭제 위험을 줄여야 합니다. 추가로 CMK 상태에 대한 알림을 받도록 [CloudWatch 경보](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html)를 설정할 수 있습니다. ### CMK를 다시 활성화하면 EKS 클러스터가 복원되나요? EKS 클러스터를 성공적으로 복원하려면 비활성화된 후 30일 이내에 CMK를 다시 활성화하는 것이 좋습니다. 하지만 EKS 클러스터의 성공적인 복원은 클러스터가 비정상/저하 상태인 동안 발생할 수 있는 자동 Kubernetes 업그레이드로 인해 API 중단 변경이 발생하는지 여부에 따라 달라집니다. ### CMK를 비활성화한 후 EKS 클러스터가 비정상/저하된 상태로 전환되는 이유는 무엇인가요? EKS 컨트롤 플레인의 API 서버는 암호화되고 API 서버의 메모리에 캐싱되는 DEK 키를 사용하여 생성/업데이트 작업 중에 모든 객체를 암호화한 후 etcd에 저장합니다. 기존 객체가 etcd에서 검색되는 경우 API 서버는 동일한 캐싱된 DEK 키를 사용하고 Kubernetes 리소스 객체를 복호화합니다. CMK를 비활성화하면 API 서버 메모리에 캐싱된 DEK 키로 인해 API 서버에 즉각적으로 미치는 영향이 보이지 않습니다. 하지만 API 서버 인스턴스가 다시 시작되면 캐싱된 DEK가 없으며 암호화 및 복호화 작업을 위해 AWS KMS를 직접 호출해야 합니다. CMK가 없으면 이 프로세스가 KMS\$1KEY\$1DISABLED 오류 코드와 함께 실패하여 API 서버가 부팅되지 않습니다. ### CMK를 삭제하면 EKS 클러스터는 어떻게 되나요? EKS 클러스터와 연결된 CMK 키를 삭제하면 복구 이후 상태가 저하됩니다. 클러스터의 CMK가 없으면 API 서버는 더 이상 새로운 Kubernetes 객체를 암호화 및 유지하는 것은 물론 앞서 암호화되어 etcd 데이터베이스에서 저장된 Kubernetes 객체를 복호화할 수 없습니다. EKS 클러스터를 더 이상 사용할 필요가 없다고 확인된 경우에만 EKS 클러스터에 대한 CMK 키 삭제를 진행해야 합니다. CMK를 찾을 수 없거나(KMS\$1KEY\$1NOT\$1FOUND) 클러스터와 연결된 CMK에 대한 권한 부여가 취소된 경우(KMS\$1GRANT\$1REVOKED) 클러스터를 복구할 수 없습니다. 클러스터 상태 및 오류 코드에 대한 자세한 내용은 [클러스터 상태 FAQ 및 해결 경로 포함 오류 코드](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html#cluster-health-status)를 참조하세요. ### CMK를 비활성화 또는 삭제했기 때문에 성능이 저하되거나 비정상인 EKS 클러스터에도 요금이 계속 부과되나요? 예. 비활성화된 CMK의 경우 EKS 컨트롤 플레인을 사용할 수 없지만 AWS는 고객이 삭제할 때까지 EKS 클러스터에 할당된 전용 인프라 리소스를 계속 실행합니다. 또한 EKS 클러스터의 정상적인 상태 및 작동을 방해하는 고객의 자발적인 조치 또는 비조치이므로 이러한 상황에서는 [서비스 약정](https://aws.amazon.com/eks/sla/)이 적용되지 않습니다. ### 비활성화된 CMK로 인해 EKS 클러스터가 비정상/저하 상태일 때 자동으로 업그레이드할 수 있나요? 예. 하지만 클러스터에 비활성화된 CMK가 있는 경우 30일 이내에 클러스터를 다시 활성화해야 합니다. 이 30일 기간 동안에는 Kubernetes 클러스터가 자동으로 업그레이드되지 않습니다. 하지만 이 기간이 경과하고 CMK를 다시 활성화하지 않으면 EKS의 Kubernetes 버전 수명 주기에 따라 클러스터가 표준 지원을 받는 다음 버전(n\$11)으로 자동 업그레이드됩니다. 영향을 받는 클러스터를 인식하면 비활성화된 CMK를 빠르게 다시 활성화하는 것이 좋습니다. EKS는 영향을 받는 클러스터를 자동으로 업그레이드하지만, 특히 클러스터가 여러 차례 자동으로 업그레이드되는 경우 Kubernetes API에 대한 변경 사항과 API 서버의 부트스트랩 프로세스에서 예기치 않은 동작이 포함될 수 있으므로 성공적인 복구가 보장되지 않습니다. ### KMS 키 별칭을 사용할 수 있나요? 예. Amazon EKS는 [KMS 키 별칭 사용을 지원합니다](https://docs.aws.amazon.com/eks/latest/APIReference/API_EncryptionConfig.html#API_EncryptionConfig_Contents). 별칭은 [Amazon Web Service KMS 키](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys)의 친숙한 이름입니다. 예를 들어 별칭을 사용하면 KMS 키를 **`1234abcd-12ab-34cd-56ef-1234567890ab`** 대신 **my-key**로 지칭할 수 있습니다. ### 자체 Kubernetes 백업 솔루션을 사용하여 클러스터 리소스를 계속 백업하고 복원할 수 있나요? 예. Kubernetes 클러스터 재해 복구, 데이터 마이그레이션 및 데이터 보호를 위해 Kubernetes 백업 솔루션(예: [Velero](https://velero.io/))을 사용할 수 있습니다. API 서버를 통해 클러스터 리소스에 액세스하는 Kubernetes 백업 솔루션을 실행하는 경우 애플리케이션에서 검색하는 모든 데이터가 클라이언트에 도달하기 전에 복호화됩니다. 이렇게 하면 다른 Kubernetes 클러스터의 클러스터 리소스를 복구할 수 있습니다. # Amazon EKS Auto Mode의 보안 고려 사항 이 주제에서는 Amazon EKS Auto Mode의 보안 아키텍처, 제어 및 모범 사례를 설명합니다. 조직이 대규모로 컨테이너화된 애플리케이션을 배포함에 따라 강력한 보안 태세를 유지하기가 점점 복잡해지고 있습니다. EKS Auto Mode는 자동화된 보안 제어를 구현하고 AWS 보안 서비스와 통합하여 클러스터 인프라, 워크로드, 데이터를 보호합니다. 강제 노드 수명 주기 관리, 자동 패치 배포와 같은 기본 제공 보안 기능으로 EKS Auto Mode는 운영 오버헤드를 줄이면서 보안 모범 사례를 유지하는 데 도움이 됩니다. 이 주제를 진행하기 전에 기본 EKS Auto Mode 개념을 숙지하고 클러스터에서 EKS Auto Mode를 활성화하기 위한 사전 조건을 검토하세요. Amazon EKS 보안에 대한 일반적인 내용은 [Amazon EKS의 보안](security.md) 섹션을 참조하세요. Amazon EKS Auto Mode는 Amazon EKS의 기존 보안 기반을 바탕으로 하며 EC2 관리형 인스턴스에 대한 추가 자동 보안 제어를 도입합니다. ## API 보안 및 인증 Amazon EKS Auto Mode는 AWS 플랫폼 보안 메커니즘을 사용하여 Amazon EKS API에 대한 호출을 보호하고 인증합니다. + Kubernetes API에 대한 액세스는 AWS IAM 자격 증명과 통합되는 EKS 액세스 항목을 통해 보호됩니다. + 자세한 내용은 [EKS 액세스 항목을 사용한 IAM 사용자에게 Kubernetes에 대한 액세스 권한 부여](access-entries.md) 단원을 참조하십시오. + 고객은 EKS 액세스 항목 구성을 통해 Kubernetes API 엔드포인트에 대한 세분화된 액세스 제어를 구현할 수 있습니다. ## 네트워크 보안 Amazon EKS Auto Mode는 여러 계층의 네트워크 보안을 지원합니다. + **VPC 통합** + Amazon Virtual Private Cloud(VPC) 내에서 작동 + 사용자 지정 VPC 구성 및 서브넷 레이아웃 지원 + 클러스터 구성 요소 간의 프라이빗 네트워킹 활성화 + 자세한 내용은 [Managing security responsibilities for Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/security.html)를 참조하세요. + **네트워크 정책** + Kubernetes 네트워크 정책에 대한 기본 지원 + 세분화된 네트워크 트래픽 규칙을 정의하는 기능 + 자세한 내용은 [Kubernetes 네트워크 정책을 통해 pod 트래픽 제한](cni-network-policy.md) 단원을 참조하세요. ## EC2 관리형 인스턴스 보안 Amazon EKS Auto Mode는 다음과 같은 보안 제어를 사용하여 EC2 관리형 인스턴스를 운영합니다. ### EC2 보안 + EC2 관리형 인스턴스는 Amazon EC2의 보안 기능을 유지합니다. + EC2 관리형 인스턴스에 대한 자세한 내용은 [Security in Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html)을 참조하세요. ### 인스턴스 수명 주기 관리 EKS Auto Mode에서 운영하는 EC2 관리형 인스턴스의 최대 수명은 21일입니다. Amazon EKS Auto Mode는 이 수명을 초과하는 인스턴스를 자동으로 종료합니다. 이 수명 주기 제한은 구성 드리프트를 방지하고 보안 태세를 유지하는 데 도움이 됩니다. ### 데이터 보호 + Amazon EC2 인스턴스 스토리지는 암호화되며 인스턴스에 직접 연결된 스토리지입니다. 자세한 내용은 [Amazon EC2의 데이터 보호](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html)를 참조하세요. + EKS Auto Mode는 루트 및 데이터 볼륨을 포함하여 생성 시 EC2 인스턴스에 연결된 볼륨을 관리합니다. EKS Auto Mode는 Kubernetes 영구 스토리지 기능을 사용하여 생성된 EBS 볼륨을 완전히 관리하지 않습니다. ### 패치 관리 + Amazon EKS Auto Mode는 관리형 인스턴스에 패치를 자동으로 적용합니다. + 패치에는 다음이 포함됩니다. + 운영 체제 업데이트 + 보안 패치 + Amazon EKS Auto Mode 구성 요소 **참고** 고객은 이러한 인스턴스에서 실행되는 워크로드를 보호하고 업데이트할 책임이 있습니다. ### 액세스 제어 + 직접 인스턴스 액세스는 제한됩니다. + SSH 액세스를 사용할 수 없습니다. + AWS Systems Manager Session Manager(SSM) 액세스를 사용할 수 없습니다. + 관리 작업은 Amazon EKS API 및 Kubernetes API를 통해 수행됩니다. ## 리소스 관리 자동화 Amazon EKS Auto Mode는 Kubernetes 영구 스토리지 기능을 사용하여 생성된 Amazon Elastic Block Store(Amazon EBS) 볼륨을 완전히 관리하지 않습니다. 또한 EKS Auto Mode는 Elastic Load Balancer(ELB)를 관리하지 않습니다. Amazon EKS Auto Mode는 이러한 리소스에 대한 일상적인 작업을 자동화합니다. ### 스토리지 보안 + AWS에서는 Kubernetes 영구 스토리지 기능으로 프로비저닝된 EBS 볼륨에 대해 암호화를 활성화할 것을 권장합니다. 자세한 내용은 [스토리지 클래스 생성](create-storage-class.md) 단원을 참조하십시오. + AWS KMS를 사용하여 저장 시 암호화 + 사용자의 AWS 계정을 구성하여 생성하는 새 EBS 볼륨 및 스냅샷 사본의 암호화를 적용할 수 있습니다. 자세한 내용은 Amazon EBS 사용 설명서의 [Enable Amazon EBS encryption by default](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html)을 참조하세요. + 자세한 내용은 [Security in Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/security.html)을 참조하세요. ### 로드 밸런서 보안 + Elastic Load Balancer의 자동 구성 + AWS Certificate Manager 통합을 통한 SSL/TLS 인증서 관리 + 로드 밸런서 액세스 제어를 위한 보안 그룹 자동화 + 자세한 내용은 [Security in Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/security.html)을 참조하세요. ## 보안 모범 사례 다음 섹션에서는 Amazon EKS Auto Mode의 보안 모범 사례를 설명합니다. + AWS IAM 정책 및 EKS 액세스 항목을 정기적으로 검토합니다. + 워크로드에 대한 최소 권한 액세스 패턴을 구현합니다. + AWS CloudTrail 및 Amazon CloudWatch를 통해 클러스터 활동을 모니터링합니다. 자세한 내용은 [API 호출을 AWS CloudTrail 이벤트로 기록](logging-using-cloudtrail.md) 및 [Amazon CloudWatch를 사용한 클러스터 데이터 모니터링](cloudwatch.md) 단원을 참조하세요. + 보안 태세 평가를 위해 AWS Security Hub를 사용합니다. + 워크로드에 적합한 포드 보안 표준을 구현합니다. # EKS 기능에 대한 보안 고려 사항 이 주제에서는 IAM 역할 구성, Kubernetes 권한, 다중 클러스터 배포 및 교차 계정 AWS 리소스 관리를 위한 아키텍처 패턴을 포함하여 EKS 기능에 대한 중요한 보안 고려 사항을 다룹니다. EKS 기능은 IAM 역할, EKS 액세스 항목 및 Kubernetes RBAC의 조합을 사용하여 AWS 서비스, 클러스터 내 Kubernetes 리소스 및 AWS CodeConnections, AWS Secrets Manager 및 기타 AWS 서비스와의 통합에 대한 보안 액세스를 제공합니다. ## 기능 IAM 역할 기능을 생성할 때 사용자는 EKS가 사용자를 대신하여 작업을 수행하는 데 사용하는 IAM 기능 역할을 제공합니다. 이 역할은 다음 조건을 충족해야 합니다. + 클러스터 및 기능 리소스와 동일한 AWS 계정에 있어야 함 + `capabilities.eks.amazonaws.com` 서비스 위탁자가 역할을 수임하도록 허용하는 신뢰 정책이 있음 + 요구 사항에 따라 기능 유형 및 사용 사례에 적합한 IAM 권한이 있어야 합니다. 필요한 각 권한에 대한 자세한 내용은 [AWS CodeConnections를 사용하여 Git 리포지토리에 연결](integration-codeconnections.md), [AWS Secrets Manager를 사용하여 애플리케이션 보안 암호 관리](integration-secrets-manager.md), [ACK 권한 구성](ack-permissions.md) 섹션을 참조하세요. 특정 사용 사례에 필요한 권한 범위를 고려하고 요구 사항을 충족하는 데 필요한 권한만 부여하는 것이 모범 사례입니다. 예를 들어 Kube Resource Orchestrator의 EKS 기능을 사용하는 경우 IAM 권한이 필요하지 않을 수 있지만 AWS Controllers for Kubernetes의 EKS 기능을 사용하는 경우 하나 이상의 AWS 서비스에 대한 전체 액세스 권한을 부여할 수 있습니다. **중요** 일부 사용 사례에서는 광범위한 관리 권한을 사용해야 할 수 있지만 특정 사용 사례에 필요한 최소 IAM 권한만 부여하여 최소 권한 원칙을 따름으로써 와일드카드 권한을 사용하는 대신 ARN 및 조건 키를 사용하여 특정 리소스에 대한 액세스를 제한합니다. 기능 IAM 역할 생성 및 구성에 대한 자세한 내용은 [Amazon EKS 기능 IAM 역할](capability-role.md) 섹션을 참조하세요. ## EKS 액세스 항목 IAM 역할로 기능을 생성하면 Amazon EKS는 클러스터에서 해당 역할에 대한 액세스 항목을 자동으로 생성합니다. 이 액세스 항목이 작동하려면 기능에 기준 Kubernetes 권한을 부여합니다. **참고** 액세스 항목은 기능이 생성되는 클러스터에 대해 생성됩니다. Argo CD를 원격 클러스터에 배포하려면 Argo CD 기능이 애플리케이션을 배포 및 관리하기 위한 적절한 권한이 있는 액세스 항목을 해당 클러스터에서 생성해야 합니다. 액세스 항목에는 다음이 포함됩니다. + 위탁자에 해당하는 IAM 역할 ARN + 기준 Kubernetes 권한을 부여하는 기능별 액세스 항목 정책 + 기능 유형에 따라 적절한 범위(클러스터 전체 또는 네임스페이스 범위) **참고** Argo CD의 경우 네임스페이스 범위 권한이 기능 구성에 지정된 네임스페이스(기본값: `argocd`)에 부여됩니다. **기능별 기본 액세스 항목 정책** 각 기능 유형은 다음과 같이 여러 기본 액세스 항목 정책을 설정하여 기능 역할에 필요한 권한을 부여합니다. **kro** + `arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy`(클러스터 범위) ResourceGraphDefinitions를 감시 및 관리하고 RGD에서 정의한 사용자 지정 리소스의 인스턴스를 생성할 권한을 부여합니다. **ACK** + `arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy`(클러스터 범위) 모든 네임스페이스에서 ACK 사용자 지정 리소스에 대한 생성, 읽기, 업데이트 및 삭제를 수행할 권한을 부여합니다. **Argo CD** + `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`(클러스터 범위) Argo CD가 리소스를 검색하고 클러스터 범위의 객체를 관리하기 위한 사용할 클러스터 수준 권한을 부여합니다. + `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`(네임스페이스 범위) Argo CD가 애플리케이션을 배포 및 관리하기 위한 네임스페이스 수준 권한을 부여합니다. 기능 구성에 지정된 네임스페이스(기본값: `argocd`)로 범위가 지정됩니다. 자세한 내용은 [액세스 정책 권한 검토](access-policy-permissions.md) 섹션을 참조하세요. ## 추가 Kubernetes 권한 일부 기능에는 기본 액세스 항목 정책 이외에 추가 Kubernetes 권한이 필요할 수 있습니다. 다음 중 하나를 사용하여 이러한 권한을 부여할 수 있습니다. + **액세스 항목 정책**: 액세스 항목에 추가 관리형 정책 연결 + **Kubernetes RBAC**: 기능의 Kubernetes 사용자를 위해 `Role` 또는 `ClusterRole` 바인딩 생성 **ACK 보안 암호 리더 권한** 일부 ACK 컨트롤러는 데이터베이스 암호와 같은 민감한 데이터를 검색하기 위해 Kubernetes 보안 암호를 읽어야 합니다. 다음 ACK 컨트롤러에는 보안 암호 읽기 액세스 권한이 필요합니다. + `acm`, `acmpca`, `documentdb`, `memorydb`, `mq`, `rds`, `secretsmanager` 보안 암호 읽기 권한을 부여하는 방법: 1. `arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy` 액세스 항목 정책을 기능의 액세스 항목에 연결 1. ACK 리소스가 보안 암호를 참조하거나 클러스터 전체 액세스 권한을 부여하는 특정 네임스페이스로 정책 범위 지정 **중요** 보안 암호 읽기 권한은 액세스 항목 정책을 연결할 때 지정한 네임스페이스로 범위가 지정됩니다. 이를 통해 기능이 액세스할 수 있는 보안 암호를 제한할 수 있습니다. **kro의 임의 리소스 권한** kro에는 ResourceGraphDefinitions에 정의된 리소스를 생성 및 관리할 권한이 필요합니다. 기본적으로 kro는 RGD 자체만 감시하고 관리할 수 있습니다. kro에 리소스를 생성할 권한을 부여하는 방법: **옵션 1: 액세스 항목 정책** `AmazonEKSAdminPolicy` 또는 `AmazonEKSEditPolicy`와 같은 사전 정의된 액세스 항목 정책을 기능의 액세스 항목에 연결합니다. **옵션 2: Kubernetes RBAC** 기능의 Kubernetes 사용자에게 필요한 권한을 부여하는 `ClusterRoleBinding`을 생성합니다. ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: kro-cluster-admin subjects: - kind: User name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: cluster-admin apiGroup: rbac.authorization.k8s.io ``` **참고** kro의 Kubernetes 사용자 이름은 `arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/KRO` 패턴을 따릅니다. 세션 이름 `/KRO`(대문자)는 EKS kro 기능에 의해 자동으로 설정됩니다. ## 기능에 필요한 IAM 권한 **Kube Resource Orchestrator(kro)** 필요한 IAM 권한이 없습니다. 연결된 정책 없이 기능 역할을 생성할 수 있습니다. kro에는 Kubernetes RBAC 권한만 필요합니다. **AWS Controllers for Kubernetes(ACK)** ACK가 생성 및 관리할 AWS 리소스를 관리할 권한이 필요합니다. 요구 사항에 따라 특정 서비스, 작업 및 리소스에 대한 권한 범위를 지정해야 합니다. IAM 역할 선택기를 사용하는 프로덕션 모범 사례를 포함하여 ACK 권한 구성에 대한 자세한 내용은 [ACK 권한 구성](ack-permissions.md) 섹션을 참조하세요. **Argo CD** 기본적으로 IAM 권한은 필요하지 않습니다. 다음과 같은 경우에 선택적 권한이 필요할 수 있습니다. + AWS Secrets Manager: Secrets Manager에 Git 리포지토리 자격 증명을 저장하는 경우 + AWS CodeConnections: Git 리포지토리 인증에 CodeConnections를 사용하는 경우 + Amazon ECR: Amazon ECR에서 OCI 형식으로 저장된 헬름 차트를 사용하는 경우 ## 보안 모범 사례 ### IAM 최소 권한 기능 리소스에 사용 사례에 필요한 권한만 부여합니다. 필요한 경우 기능에 광범위한 관리 권한을 부여할 수 없음을 의미하지는 않습니다. 이러한 경우 해당 리소스에 대한 액세스를 적절하게 규제해야 합니다. **기능 역할**: + **ACK**: 가능하면 사용 사례 및 요구 사항에 따라 팀에 필요한 특정 AWS 서비스 및 리소스로 IAM 권한을 제한합니다. + **Argo CD**: 특정 Git 리포지토리 및 Kubernetes 네임스페이스에 대한 액세스 제한 + **kro**: 신뢰 정책에 대한 기능 역할이 필요하지만 IAM 권한은 필요하지 않음(클러스터 RBAC만 사용) **예제**: `"Resource": "*"` 대신 특정 리소스 또는 리소스 그룹에 대한 패턴을 지정합니다. ``` "Resource": [ "arn:aws:s3:::my-app-*", "arn:aws:rds:us-west-2:111122223333:db:prod-*" ] ``` IAM 조건 키를 사용하여 액세스를 추가로 제한합니다. ``` "Condition": { "StringEquals": { "aws:ResourceTag/Environment": "production" } } ``` 추가 IAM 구성 정보는 각 기능의 고려 사항 섹션을 참조하세요. ### Argo CD 보안 암호에 대한 네임스페이스 격리 관리형 Argo CD 기능은 구성된 네임스페이스(기본값: `argocd`) 내 모든 Kubernetes 보안 암호에 액세스할 수 있습니다. 최적의 보안 태세를 유지 관리하려면 다음 네임스페이스 격리 사례를 따릅니다. + Argo CD 네임스페이스 내 Argo CD 관련 보안 암호만 유지 + 관련되지 않은 애플리케이션 보안 암호를 Argo CD와 동일한 네임스페이스에 저장하지 않음 + Argo CD 작업에 필요하지 않은 애플리케이션 보안 암호에 별도의 네임스페이스 사용 이 격리를 통해 Argo CD의 보안 암호 액세스는 Git 리포지토리 인증 및 기타 Argo CD 관련 작업에 필요한 자격 증명으로만 제한됩니다. ### Kubernetes RBAC 기능 리소스를 생성 및 관리할 수 있는 사용자 및 서비스 계정을 제어합니다. 적절한 RBAC 정책을 사용하여 전용 네임스페이스에 기능 리소스를 배포하는 것이 모범 사례입니다. 예제: ACK에서 작업할 RBAC 역할. 이를 통해 `app-team` 네임스페이스에서 S3 버킷 리소스를 관리할 수 있습니다. ``` apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: ack-s3-manager namespace: app-team rules: - apiGroups: ["s3.services.k8s.aws"] resources: ["buckets"] verbs: ["get", "list", "create", "update", "delete"] ``` ### 감사 로깅 **CloudTrail**: 모든 EKS 기능 API 작업(생성, 업데이트, 삭제)이 AWS CloudTrail에 기록됩니다. 다음을 추적하도록 CloudTrail 로깅을 활성화합니다. + 기능을 생성하거나 수정한 사람 + 기능 구성이 변경된 시점 + 사용 중인 기능 역할 ### 네트워크 액세스 및 VPC 엔드포인트 #### 프라이빗 Argo CD API 액세스 하나 이상의 VPC 엔드포인트를 호스팅된 Argo CD 엔드포인트에 연결하여 Argo CD API 서버에 대한 액세스를 제한할 수 있습니다. 그러면 퍼블릭 인터넷을 통과하지 않고도 VPC 내에서 프라이빗으로 연결할 수 있습니다. VPC 엔드포인트는 Argo CD 웹 UI 및 Argo CD API(CLI 액세스 포함) 모두에 대한 액세스를 제공합니다. **참고** 호스팅된 Argo CD API 엔드포인트(eks-capabilities.*region*.amazonaws.com 사용)에 연결된 VPC 엔드포인트는 VPC 엔드포인트 정책을 지원하지 않습니다. #### 프라이빗 클러스터에 배포 Argo CD 기능은 애플리케이션을 완전한 프라이빗 EKS 클러스터에 배포하여 VPC 피어링 또는 복잡한 네트워킹 구성에 대한 필요성을 없앰으로써 운영상 상당한 이점을 제공합니다. 그러나 이 아키텍처를 설계하는 경우 Argo CD가 Git 리포지토리(퍼블릭일 수 있음)에서 구성을 가져와 프라이빗 클러스터에 적용하는지 고려합니다. 다음을 확인합니다. + 민감한 워크로드에 대해 프라이빗 Git 리포지토리 사용 + 적절한 Git 리포지토리 액세스 제어 및 인증 구현 + 병합하기 전에 풀 요청을 통해 변경 사항 검토 및 승인 + 배포가 발생할 수 있는 시점을 제어하기 위해 Argo CD의 동기화 기간 사용 고려 + 권한 없는 구성 변경 사항에 대한 Argo CD 감사 로그 모니터링 ### 규정 준수 EKS 기능은 완전관리형이며 Amazon EKS의 규정 준수 인증을 받았습니다. 최신 규정 준수 정보는 [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/)을 참조하세요. ## 다음 단계 + [ACK 권한 구성](ack-permissions.md) - ACK에 대한 IAM 권한 구성 + [kro 권한 구성](kro-permissions.md) - kro에 대한 Kubernetes RBAC 구성 + [Argo CD 권한 구성](argocd-permissions.md) - Argo CD에 대한 Identity Center 통합 구성 + [EKS 기능 문제 해결](capabilities-troubleshooting.md) - 보안 및 권한 문제 해결 # Amazon EKS용 자격 증명 및 액세스 관리 AWS Identity and Access Management(IAM)는 AWS 리소스에 대한 관리자의 액세스를 안전하게 제어하는 데 도움이 되는 AWS 서비스입니다. IAM 관리자는 어떤 사용자가 Amazon EKS 리소스를 사용할 수 있는 *인증*(로그인) 및 *권한*(권한 있음)을 받을 수 있는지를 제어합니다. IAM은 추가 비용 없이 사용할 수 있는 AWS 서비스입니다. ## 대상 AWS ID 및 액세스 관리(IAM)를 사용하는 방법은 Amazon EKS에서 수행하는 작업에 따라 다릅니다. **서비스 사용자** – Amazon EKS 서비스를 사용하여 작업을 수행하는 경우 필요한 자격 증명과 권한을 관리자가 제공합니다. 다른 Amazon EKS 기능을 사용하여 작업을 수행한다면 추가 권한이 필요할 수 있습니다. 액세스 권한 관리 방법을 이해하면 관리자에게 올바른 권한을 요청하는 데 도움이 됩니다. Amazon EKS의 기능에 액세스할 수 없다면 [IAM 문제 해결](security-iam-troubleshoot.md) 부분을 참조하세요. **서비스 관리자** – 사내 Amazon EKS 리소스를 책임지고 있다면 Amazon EKS에 대한 완전한 액세스 권한이 있을 것입니다. 서비스 관리자는 서비스 사용자가 액세스해야 하는 Amazon EKS 기능과 리소스를 결정합니다. 그런 다음 IAM 관리자에게 요청을 제출하여 서비스 사용자의 권한을 변경해야 합니다. 이 페이지의 정보를 검토하여 IAM의 기본 개념을 이해합니다. 귀사에서 Amazon EKS와 함께 IAM을 사용하는 방법에 대해 자세히 알아보려면 [Amazon EKS가 IAM과 작동하는 방식](security-iam-service-with-iam.md) 부분을 참조하세요. **IAM 관리자** - IAM 관리자라면 Amazon EKS에 대한 액세스 관리 정책 작성 방법을 자세히 알고 싶을 수도 있습니다. IAM에서 사용할 수 있는 Amazon EKS 자격 증명 기반 정책 예제를 보려면 [Amazon EKS 자격 증명 기반 정책 예제](security-iam-id-based-policy-examples.md) 부분을 참조하세요. ## ID를 통한 인증 인증은 ID 자격 증명을 사용하여 AWS에 로그인하는 방식입니다. AWS 계정 루트 사용자나 IAM 사용자로 또는 IAM 역할을 수임하여 *인증*(AWS에 로그인)되어야 합니다. ID 소스를 통해 제공된 자격 증명을 사용하여 페더레이션 ID로 AWS에 로그인할 수 있습니다. AWS IAM ID 센터 사용자, 회사의 통합 인증, Google 또는 Facebook 자격 증명은 페더레이션 ID의 예입니다. 페더레이션 ID로 로그인할 때 관리자가 이전에 IAM 역할을 사용하여 ID 페더레이션을 설정했습니다. 연동을 사용하여 AWS에 액세스하면 간접적으로 역할을 수임합니다. 사용자 유형에 따라AWS Management Console 또는 AWS 액세스 포털에 로그인할 수 있습니다. AWS 로그인에 대한 자세한 내용은 * AWS 로그인 사용 설명서*에서 [AWS 계정에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)을 참조하세요. AWS에 프로그래밍 방식으로 액세스하는 경우, AWS에서는 보안 인증 정보를 사용하여 요청에 암호화 방식으로 서명할 수 있는 소프트웨어 개발 키트(SDK) 및 명령줄 인터페이스(CLI)를 제공합니다. AWS 도구를 사용하지 않는 경우 요청에 직접 서명해야 합니다. 권장 방법을 사용하여 요청에 직접 서명하는 방법에 대한 자세한 내용은 *IAM 사용 설명서*의 [AWS API 요청에 서명](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html)을 참조하세요. 사용하는 인증 방법에 상관없이 추가 보안 정보를 제공해야 할 수도 있습니다. 예를 들어, AWS는 다중 인증(MFA)을 사용하여 계정의 보안을 강화하는 것을 권장합니다. 자세한 내용은 * AWS IAM ID 센터 사용 설명서*의 [Multi-factor 인증](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)과 *IAM 사용 설명서*의 [AWS에서 다단계 인증(MFA) 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)을 참조하세요. ### AWS 계정 루트 사용자 AWS 계정을 생성할 때는 해당 계정의 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한이 있는 단일 로그인 ID로 시작합니다. 이 자격 증명은 AWS 계정 *루트 사용자*라고 하며, 계정을 생성할 때 사용한 이메일 주소와 암호로 로그인하여 액세스합니다. 일상적인 작업에 루트 사용자를 사용하지 않을 것을 강력히 권장합니다. 루트 사용자 자격 증명을 보호하고 루트 사용자만 수행할 수 있는 작업을 수행하는 데 사용합니다. 루트 사용자로 로그인해야 하는 전체 작업 목록은 *IAM 사용 설명서*의 [루트 사용자 자격 증명이 필요한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)을 참조하세요. ### IAM 사용자 및 그룹 [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)는 단일 개인 또는 애플리케이션에 대한 특정 권한을 가지고 있는 AWS 계정 내 ID입니다. 가능하면 암호 및 액세스 키와 같은 장기 자격 증명이 있는 IAM 사용자를 생성하는 대신 임시 자격 증명을 사용하는 것이 좋습니다. 하지만 IAM 사용자의 장기 자격 증명이 필요한 특정 사용 사례가 있는 경우, 액세스 키를 교체하는 것이 좋습니다. 자세한 내용은 *IAM 사용 설명서*의 [장기 보안 인증이 필요한 사용 사례의 경우, 정기적으로 액세스 키 교체](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials)를 참조하세요. [IAM 그룹](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)은 IAM 사용자 컬렉션을 지정하는 자격 증명입니다. 사용자는 그룹으로 로그인할 수 없습니다. 그룹을 사용하여 여러 사용자의 권한을 한 번에 지정할 수 있습니다. 그룹을 사용하면 대규모 사용자 집합의 권한을 더 쉽게 관리할 수 있습니다. 예를 들어, IAMAdmins**라는 그룹이 있고 이 그룹에 IAM 리소스를 관리할 권한을 부여할 수 있습니다. 사용자는 역할과 다릅니다. 사용자는 한 사람 또는 애플리케이션과 고유하게 연결되지만, 역할은 해당 역할이 필요한 사람이라면 누구나 수임할 수 있습니다. 사용자는 영구적인 장기 보안 인증 정보를 가지고 있지만, 역할은 임시 보안 인증만 제공합니다. 자세한 정보는 *IAM 사용 설명서*의 [IAM 사용자를 만들어야 하는 경우(역할이 아님)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)를 참조하세요. ### IAM 역할 [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)은 특정 권한을 가지고 있는 AWS 계정 내 ID입니다. IAM 사용자와 유사하지만, 특정 개인과 연결되지 않습니다. [역할 전환](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)하여 AWS Management Console에서 IAM 역할을 임시로 수임할 수 있습니다. AWS CLI 또는 AWS API 작업을 직접 호출하거나 사용자 지정 URL을 사용하여 역할을 수임할 수 있습니다. 역할 사용 방법에 대한 자세한 정보는 *IAM 사용 설명서*의 [IAM 역할 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html)을 참조하세요. 임시 보안 인증이 있는 IAM 역할은 다음과 같은 상황에서 유용합니다. + **페더레이션 사용자 액세스** - 페더레이션 ID에 권한을 부여하려면 역할을 생성하고 해당 역할의 권한을 정의합니다. 페더레이션 ID가 인증되면 역할이 연결되고 역할에 정의된 권한이 부여됩니다. 페더레이션 역할에 대한 자세한 내용은 *IAM 사용 설명서*의 [서드 파티 ID 공급자의 역할 만들기](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html)를 참조하세요. IAM Identity Center를 사용하는 경우, 권한 집합을 구성합니다. 인증 후 ID가 액세스할 수 있는 항목을 제어하기 위해 IAM Identity Center는 권한 집합을 IAM의 역할과 연관짓습니다. 권한 집합에 대한 자세한 내용은 * AWS IAM Identity Center 사용 설명서*의 [권한 집합](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)을 참조하세요. + **임시 IAM 사용자 권한** - IAM 사용자 또는 역할은 IAM 역할을 수임하여 특정 작업에 대한 다양한 권한을 임시로 받을 수 있습니다. + **교차 계정 액세스** - IAM 역할을 사용하여 다른 계정의 사용자(신뢰할 수 있는 보안 주체)가 내 계정의 리소스에 액세스하도록 허용할 수 있습니다. 역할은 교차 계정 액세스를 부여하는 기본적인 방법입니다. 그러나 일부 AWS 서비스를 사용하면 역할을 (프록시로 사용하는 대신) 리소스에 정책을 직접 연결할 수 있습니다. 교차 계정 액세스에 대한 역할과 리소스 기반 정책의 차이점을 알아보려면 **IAM 사용 설명서의 [IAM의 교차 계정 리소스 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)를 참조하세요. + **교차 서비스 액세스** - 일부 AWS 서비스는 다른 AWS 서비스의 기능을 사용합니다. 예를 들어, 서비스에서 직접 호출하면 일반적으로 해당 서비스는 Amazon EC2에서 애플리케이션을 실행하거나 Amazon S3에 객체를 저장합니다. 서비스는 직접 호출하는 보안 주체의 권한을 사용하거나, 서비스 역할을 사용하거나, 또는 서비스 연결 역할을 사용하여 이 작업을 수행할 수 있습니다. + **전달 액세스 세션(FAS)** - IAM 사용자 또는 역할을 사용하여 AWS에서 작업을 수행하는 사람은 보안 주체로 간주됩니다. 일부 서비스를 사용하는 경우, 다른 서비스에서 다른 작업을 시작하는 작업을 수행할 수 있습니다. FAS는 AWS 서비스를 직접 호출하는 주체의 권한을 요청하는 AWS 서비스와 결합하여 다운스트림 서비스에 요청합니다. FAS 요청은 서비스에서 완료를 위해 다른 AWS 서비스 또는 리소스와의 상호 작용이 필요한 요청을 받은 경우에만 이루어집니다. 이 경우, 두 작업을 모두 수행할 수 있는 권한이 있어야 합니다. FAS 요청 시 정책 세부 정보는 [전달 액세스 세션](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)을 참조하세요. + **서비스 역할** - 서비스 역할은 서비스가 사용자를 대신하여 작업을 수행하기 위해 맡는 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)입니다. IAM 관리자는 IAM 내에서 서비스 역할을 생성, 수정 및 삭제할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [AWS서비스에 대한 권한을 위임할 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)을 참조하세요. + **서비스 연결 역할** - 서비스 연결 역할은 AWS 서비스에 연결된 서비스 역할의 한 유형입니다. 서비스는 사용자를 대신하여 태스크를 수행하기 위해 역할을 수임할 수 있습니다. 서비스 연결 역할은 AWS계정에 나타나고, 서비스가 소유합니다. IAM 관리자는 서비스 연결 역할의 권한을 볼 수 있지만 편집은 할 수 없습니다. + **Amazon EC2에서 실행 중인 애플리케이션** – IAM 역할을 사용하여 EC2 인스턴스에서 실행되고 AWS CLI 또는 AWS API 요청을 수행하는 애플리케이션의 임시 자격 증명을 관리할 수 있습니다. 이는 EC2 인스턴스 내에 액세스 키를 저장할 때 권장되는 방법입니다. EC2 인스턴스에 AWS역할을 할당하고 해당 역할을 모든 애플리케이션에서 사용할 수 있도록 하려면 인스턴스에 연결된 인스턴스 프로필을 생성합니다. 인스턴스 프로필에는 역할이 포함되어 있으며 EC2 인스턴스에서 실행되는 프로그램이 임시 보안 인증을 얻을 수 있습니다. 자세한 정보는 *IAM 사용 설명서*의 [IAM 역할을 사용하여 Amazon EC2 인스턴스에서 실행되는 애플리케이션에 권한 부여](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)를 참조하세요. IAM 역할을 사용할지 또는 IAM 사용자를 사용할지를 알아보려면 [IAM 사용 설명서](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role)의 *IAM 역할(사용자 대신)을 생성하는 경우,*를 참조하세요. ## 정책을 사용한 액세스 관리 정책을 생성하고 AWS ID 또는 리소스에 연결하여 AWS에서 내 액세스를 제어합니다. 정책은 ID 또는 리소스와 연결될 때 해당 권한을 정의하는 AWS의 객체입니다. AWS는 보안 주체(사용자, 루트 사용자 또는 역할 세션)가 요청을 보낼 때 이러한 정책을 평가합니다. 정책에서 권한은 요청이 허용되거나 거부되는 지를 결정합니다. 대부분의 정책은 AWS에 JSON 문서로 저장됩니다. JSON 정책 문서의 구조와 콘텐츠에 대한 자세한 내용은 *IAM 사용 설명서*의 [JSON 정책 개요](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)를 참조하세요. 관리자는 AWSJSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지를 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다. 기본적으로, 사용자 및 역할에는 어떠한 권한도 없습니다. 사용자에게 사용자가 필요한 리소스에서 작업을 수행할 권한을 부여하려면 IAM 관리자가 IAM 정책을 생성하면 됩니다. 그런 다음 관리자가 IAM 정책을 역할에 추가하고, 사용자가 역할을 수임할 수 있습니다. IAM 정책은 작업을 수행하기 위해 사용하는 방법과 상관없이 작업에 대한 권한을 정의합니다. 예를 들어, `iam:GetRole` 작업을 허용하는 정책이 있다고 가정합니다. 해당 정책이 있는 사용자는 AWS Management Console, AWS CLI 또는 AWS API에서 역할 정보를 가져올 수 있습니다. ### 자격 증명 기반 정책 ID 기반 정책은 IAM 사용자, 사용자 그룹 또는 역할과 같은 ID에 연결할 수 있는 JSON 권한 정책 문서입니다. 이러한 정책은 사용자와 역할이 어떤 리소스와 어떤 조건에서 어떤 작업을 수행할 수 있는지를 제어합니다. 자격 증명 기반 정책을 생성하는 방법을 알아보려면 *IAM 사용 설명서*의 [IAM 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)을 참조하세요. 보안 인증 기반 정책은 *인라인 정책* 또는 *관리형 정책*으로 한층 더 분류할 수 있습니다. 인라인 정책은 단일 사용자, 그룹 또는 역할에 직접 포함됩니다. 관리형 정책은 AWS 계정에 속한 다수의 사용자, 그룹 및 역할에게 독립적으로 추가할 수 있는 정책입니다. 관리형 정책에는 AWS 관리형 정책과 고객 관리형 정책이 포함되어 있습니다. 관리형 정책 또는 인라인 정책을 선택하는 방법을 알아보려면 *IAM 사용 설명서*의 [관리형 정책과 인라인 정책의 선택](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline)을 참조하세요. ### 리소스 기반 정책 리소스 기반 정책은 리소스에 연결하는 JSON 정책 설명서입니다. 리소스 기반 정책의 예제는 IAM *역할 신뢰 정책*과 Amazon S3 *버킷 정책*입니다. 리소스 기반 정책을 지원하는 서비스에서 서비스 관리자는 이러한 정책을 사용하여 특정 리소스에 대한 액세스를 통제할 수 있습니다. 정책이 연결된 리소스의 경우 정책은 지정된 위탁자가 해당 리소스와 어떤 조건에서 어떤 작업을 수행할 수 있는지를 정의합니다. 리소스 기반 정책에서 [보안 주체를 지정](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)해야 합니다. 보안 주체에는 계정, 사용자, 역할, 페더레이션 사용자 또는 AWS 서비스가 포함될 수 있습니다. 리소스 기반 정책은 해당 서비스에 있는 인라인 정책입니다. 리소스 기반 정책에서는 IAM의 AWS 관리형 정책을 사용할 수 없습니다. ### 액세스 제어 목록(ACL) 액세스 제어 목록(ACL)은 어떤 위탁자(계정 멤버, 사용자 또는 역할)가 리소스에 액세스할 수 있는 권한을 가지고 있는지를 제어합니다. ACL은 JSON 정책 문서 형식을 사용하지 않지만 리소스 기반 정책과 유사합니다. Amazon S3, AWS WAF 및 Amazon VPC는 ACL을 지원하는 대표적인 서비스입니다. ACL에 관한 자세한 내용은 *Amazon Simple Storage Service 개발자 가이드*의 [액세스 제어 목록(ACL) 개요](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)를 참조하세요. ### 기타 정책 타입 AWS는 비교적 일반적이지 않은 추가 정책 유형을 지원합니다. 이러한 정책 타입은 더 일반적인 정책 유형에 따라 사용자에게 부여되는 최대 권한을 설정할 수 있습니다. + **권한 경계** – 권한 경계는 ID 기반 정책에 따라 IAM 엔터티(IAM 사용자 또는 역할)에 부여할 수 있는 최대 권한을 설정하는 고급 기능입니다. 개체에 대한 권한 경계를 설정할 수 있습니다. 그 결과로 얻는 권한은 객체의 자격 증명 기반 정책과 그 권한 경계의 교집합입니다. `Principal` 필드에서 사용자나 역할을 지정하는 리소스 기반 정책은 권한 경계를 통해 제한되지 않습니다. 이러한 정책 중 하나에 포함된 명시적 거부는 허용을 재정의합니다. 권한 경계에 대한 자세한 정보는 *IAM 사용 설명서*의 [IAM 엔티티에 대한 권한 경계](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)를 참조하세요. + **서비스 제어 정책(SCPs)** – SCP는 AWS조직에서 조직 또는 조직 단위(OU)에 대한 최대 권한을 지정하는 JSON 정책입니다. AWS Organizations는 비즈니스가 소유하는 여러 AWS 계정을 그룹화하고 중앙에서 관리할 수 있는 서비스입니다. 조직에서 모든 기능을 활성화할 경우, 서비스 제어 정책(SCP)을 임의의 또는 모든 계정에 적용할 수 있습니다. SCP는 각 AWS 계정 루트 사용자를 비롯하여 멤버 계정의 엔터티에 대한 권한을 제한합니다. SCP에 대한 자세한 내용은 * AWS 조직 사용 설명서*에서 [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)을 참조하세요. + **세션 정책** – 세션 정책은 역할 또는 페더레이션 사용자에 대해 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책입니다. 결과적으로 얻는 세션의 권한은 사용자 또는 역할의 자격 증명 기반 정책과 세션 정책의 교집합입니다. 또한 권한을 리소스 기반 정책에서 가져올 수도 있습니다. 이러한 정책 중 하나에 포함된 명시적 거부는 허용을 재정의합니다. 자세한 내용은 *IAM 사용 설명서*의 [세션 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)을 참조하세요. ### 여러 정책 유형 여러 정책 유형이 요청에 적용되는 경우, 결과 권한은 이해하기가 더 복잡합니다. 여러 정책 유형이 관련될 때 AWS가 요청을 허용할지를 결정하는 방법을 알아보려면 IAM 사용 설명서**의 [정책 평가 로직](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)을 참조하세요. # Amazon EKS가 IAM과 작동하는 방식 IAM을 사용하여 Amazon EKS에 대한 액세스를 관리하기 전에 Amazon EKS에서 사용할 수 있는 IAM 기능을 이해해야 합니다. Amazon EKS 및 기타 AWS 서비스에서 IAM을 사용하는 방법을 자세히 알아보려면 *IAM 사용 설명서*의 [IAM으로 작업하는 AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하세요. **Topics** + [Amazon EKS 자격 증명 기반 정책](#security-iam-service-with-iam-id-based-policies) + [Amazon EKS 리소스 기반 정책](#security-iam-service-with-iam-resource-based-policies) + [Amazon EKS 태그를 기반으로 권한 부여](#security-iam-service-with-iam-tags) + [Amazon EKS IAM 역할](#security-iam-service-with-iam-roles) ## Amazon EKS 자격 증명 기반 정책 IAM ID 기반 정책을 사용하면 허용되거나 거부되는 작업과 리소스뿐 아니라 작업이 허용되거나 거부되는 조건을 지정할 수 있습니다. Amazon EKS는 특정 작업, 리소스 및 조건 키를 지원합니다. JSON 정책에서 사용하는 모든 요소에 대해 알아보려면 *IAM 사용자 설명서*의 [IAM JSON 정책 요소 참조](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)를 참조하세요. ### 작업 관리자는 AWSJSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지를 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다. JSON 정책의 `Action` 요소는 정책에서 액세스를 허용하거나 거부하는 데 사용할 수 있는 작업을 설명합니다. 일반적으로 정책 작업의 이름은 연결된 AWSAPI 작업의 이름과 동일합니다. 일치하는 API 작업이 없는 *권한 전용 작업* 같은 몇 가지 예외도 있습니다. 정책에서 여러 작업이 필요한 몇 가지 작업도 있습니다. 이러한 추가 작업을 일컬어 *종속 작업*이라고 합니다. 연결된 작업을 수행할 수 있는 권한을 부여하기 위한 정책에 작업을 포함하세요. Amazon EKS의 정책 작업은 작업 앞에 `eks:` 접두사를 사용합니다. 예를 들어, Amazon EKS 클러스터에 대한 기술 정보를 다운로드할 수 있는 권한을 부여하려면 정책에 `DescribeCluster` 작업을 포함합니다. 정책 문에는 `Action` 또는 `NotAction` 요소가 포함되어야 합니다. 명령문 하나에 여러 태스크를 지정하려면 다음과 같이 쉼표로 구분합니다. ``` "Action": ["eks:action1", "eks:action2"] ``` 와일드카드(\$1)를 사용하여 여러 작업을 지정할 수 있습니다. 예를 들어, `Describe`라는 단어로 시작하는 모든 태스크를 지정하려면 다음 태스크를 포함합니다. ``` "Action": "eks:Describe*" ``` Amazon EKS 작업의 목록을 보려면 *서비스 인증 참조*의 [Amazon Elastic Kubernetes Service에서 정의한 작업](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)을 참조하세요. ### 리소스 관리자는 AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지를 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다. `Resource` JSON 정책 요소는 작업이 적용되는 하나 이상의 객체를 지정합니다. 문에는 `Resource`또는 `NotResource`요소가 반드시 추가되어야 합니다. 모범 사례에 따라 [Amazon 리소스 이름(ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)을 사용하여 리소스를 지정합니다. *리소스 수준 권한*이라고 하는 특정 리소스 유형을 지원하는 작업에 대해 이를 수행할 수 있습니다. 작업 나열과 같이 리소스 수준 권한을 지원하지 않는 작업의 경우, 와일드카드(\$1)를 사용하여 명령문이 모든 리소스에 적용됨을 나타냅니다. ``` "Resource": "*" ``` Amazon EKS 클러스터 리소스의 ARN은 다음과 같습니다. ``` arn:aws:eks:region-code:account-id:cluster/cluster-name ``` ARN 형식에 대한 자세한 내용은 [Amazon 리소스 이름(ARN) 및 AWS 서비스 네임스페이스](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)를 참조하세요. 예를 들어, 문에서 이름이 *my-cluster*인 클러스터를 지정하려면 다음 ARN을 사용하세요. ``` "Resource": "arn:aws:eks:region-code:111122223333:cluster/my-cluster" ``` 특정 계정 및 AWS 리전에 속한 모든 클러스터를 지정하려면 와일드카드(\$1)를 사용합니다. ``` "Resource": "arn:aws:eks:region-code:111122223333:cluster/*" ``` 리소스 생성 작업과 같은 일부 Amazon EKS 작업은 특정 리소스에서 수행할 수 없습니다. 이러한 경우, 와일드카드(\$1)를 사용해야 합니다. ``` "Resource": "*" ``` Amazon EKS 리소스 유형 및 해당 ARN의 목록을 보려면 *서비스 인증 참조*의 [Amazon Elastic Kubernetes Service에서 정의한 리소스](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-resources-for-iam-policies)를 참조하세요. 각 리소스의 ARN을 지정할 수 있는 작업을 알아보려면 [Amazon Elastic Kubernetes Service에서 정의한 작업](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)을 참조하세요. ### 조건 키 Amazon EKS는 자체 조건 키 세트를 정의하며 일부 글로벌 조건 키 사용도 지원합니다. 모든 AWS전역 조건 키를 보려면 IAM 사용 설명서의 [AWS전역 조건 컨텍스트 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)를 참조하세요.** OpenID Connect 공급자를 클러스터에 연결할 때 조건 키를 설정할 수 있습니다. 자세한 내용은 [IAM; 정책 예](authenticate-oidc-identity-provider.md#oidc-identity-provider-iam-policy) 섹션을 참조하세요. 모든 Amazon EC2 작업은 `aws:RequestedRegion` 및 `ec2:Region` 조건 키를 지원합니다. 자세한 내용은 [예제: 특정 AWS 리전으로 액세스 제한](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region)을 참조하세요. Amazon EKS 조건 키 목록을 보려면 *서비스 인증 참조*의 [Amazon Elastic Kubernetes Service의 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys)를 참조하세요. 조건 키를 사용할 수 있는 작업과 리소스를 알아보려면 [Amazon Elastic Kubernetes Service에서 정의한 작업](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)을 참조하세요. ### 예제 Amazon EKS 자격 증명 기반 정책 예제를 보려면 [Amazon EKS 자격 증명 기반 정책 예제](security-iam-id-based-policy-examples.md) 섹션을 참조하세요. Amazon EKS 클러스터를 생성할 경우, 클러스터를 생성하는 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)에게는 Amazon EKS 제어 영역의 클러스터 역할 기반 액세스 제어(RBAC) 구성에 `system:masters` 권한이 자동으로 부여됩니다. 이 보안 주체는 표시되는 구성에 나타나지 않으므로 클러스터를 원래 생성한 보안 주체를 추적해야 합니다. 추가 IAM 위탁자에 클러스터와 상호 작용할 수 있는 기능을 부여하려면 Kubernetes 내에서 `aws-auth ConfigMap`을 편집하고 `aws-auth ConfigMap`에 지정하는 `group`의 이름으로 Kubernetes `rolebinding` 또는 `clusterrolebinding`을 생성합니다. ConfigMap 작업에 대한 자세한 내용은 [IAM 사용자 및 역할에 Kubernetes API에 대한 액세스 권한 부여](grant-k8s-access.md) 세션을 참조하세요. ## Amazon EKS 리소스 기반 정책 Amazon EKS는 리소스 기반 정책을 지원하지 않습니다. ## Amazon EKS 태그를 기반으로 권한 부여 Amazon EKS 리소스에 태그를 연결하거나 Amazon EKS에 대한 요청에서 태그를 전달할 수 있습니다. 태그에 근거하여 액세스를 제어하려면 `aws:ResourceTag/key-name `, `aws:RequestTag/key-name `또는 `aws:TagKeys`조건 키를 사용하여 정책의 [조건 요소](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)에 태그 정보를 제공합니다. Amazon EKS 리소스 태깅에 대한 자세한 내용은 [태그를 사용하여 Amazon EKS 리소스 구성](eks-using-tags.md) 섹션을 참조하세요. 조건 키의 태그를 사용할 수 있는 작업에 대한 자세한 내용은 [Service Authorization Reference](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html)에서 [Amazon EKS가 정의한 작업](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)을 참조하세요. ## Amazon EKS IAM 역할 IAM [역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)은 특정 권한을 가지고 있는 AWS 계정 내 엔터티입니다. ### Amazon EKS에서 임시 자격 증명 사용 임시 보안 인증을 사용하여 페더레이션을 통해 로그인하거나, IAM 역할을 맡거나, 교차 계정 역할을 맡을 수 있습니다. [AssumeRole 또는 [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) 같은 AWS](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) STS API 작업을 직접 호출하여 임시 보안 자격 증명을 가져옵니다. Amazon EKS는 임시 자격 증명 사용을 지원합니다. ### 서비스 연결 역할 [서비스 연결 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)을 사용하면 AWS 서비스에서 다른 서비스의 리소스에 액세스하여 사용자 대신 작업을 완료할 수 있습니다. 서비스 연결 역할은 IAM 계정에 나타나고 서비스가 소유합니다. 관리자는 서비스 연결 역할의 권한을 볼 수 있지만 편집은 할 수 없습니다. Amazon EKS는 서비스 연결 역할을 지원합니다. Amazon EKS 서비스 연결 역할 생성 또는 관리에 대한 자세한 내용은 [Amazon EKS에 대해 서비스 연결 역할 사용](using-service-linked-roles.md) 섹션을 참조하세요. ### 서비스 역할 이 기능을 사용하면 서비스가 사용자를 대신하여 [서비스 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-role)을 수임할 수 있습니다. 이 역할을 사용하면 서비스가 다른 서비스의 리소스에 액세스해 사용자를 대신해 작업을 완료할 수 있습니다. 서비스 역할은 IAM 계정에 나타나고, 해당 계정이 소유합니다. 즉, IAM 관리자가 이 역할에 대한 권한을 변경할 수 있습니다. 그러나 권한을 변경하면 서비스의 기능이 손상될 수 있습니다. Amazon EKS는 서비스 역할을 지원합니다. 자세한 내용은 [Amazon EKS 클러스터 IAM 역할](cluster-iam-role.md) 및 [Amazon EKS 노드 IAM 역할](create-node-role.md) 섹션을 참조하세요. ### Amazon EKS에서 IAM 역할 선택 Amazon EKS에서 클러스터 리소스를 생성할 경우 Amazon EKS가 사용자 대신 다른 여러 AWS 리소스에 액세스하도록 허용하는 역할을 선택해야 합니다. 이전에 서비스 역할을 생성한 경우 Amazon EKS는 선택할 수 있는 역할 목록을 제공합니다. Amazon EKS 관리형 정책이 연결된 역할을 선택하는 것이 중요합니다. 자세한 내용은 [기존 클러스터 역할 확인](cluster-iam-role.md#check-service-role) 및 [기존 노드 역할 확인](create-node-role.md#check-worker-node-role) 섹션을 참조하세요. # Amazon EKS 자격 증명 기반 정책 예제 기본적으로 IAM 사용자 및 역할은 Amazon EKS 리소스를 생성하거나 수정할 수 있는 권한이 없습니다. 또한 AWS Management Console, AWS CLI 또는 AWS API를 사용해 작업을 수행할 수 없습니다. IAM 관리자는 지정된 리소스에서 특정 API 작업을 수행할 수 있는 권한을 사용자와 역할에게 부여하는 IAM 정책을 생성해야 합니다. 그런 다음 관리자는 해당 권한이 필요한 IAM 사용자 또는 그룹에 이러한 정책을 연결해야 합니다. 이러한 예제 JSON 정책 문서를 사용하여 IAM ID 기반 정책을 생성하는 방법을 알아보려면 *IAM 사용자 설명서*의 [JSON 탭에서 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)을 참조하세요. Amazon EKS 클러스터를 생성할 경우, 클러스터를 생성하는 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)에게는 Amazon EKS 제어 영역의 클러스터 역할 기반 액세스 제어(RBAC) 구성에 `system:masters` 권한이 자동으로 부여됩니다. 이 보안 주체는 표시되는 구성에 나타나지 않으므로 클러스터를 원래 생성한 보안 주체를 추적해야 합니다. 추가 IAM 위탁자에 클러스터와 상호 작용할 수 있는 기능을 부여하려면 Kubernetes 내에서 `aws-auth ConfigMap`을 편집하고 `aws-auth ConfigMap`에 지정하는 `group`의 이름으로 Kubernetes `rolebinding` 또는 `clusterrolebinding`을 생성합니다. ConfigMap 작업에 대한 자세한 내용은 [IAM 사용자 및 역할에 Kubernetes API에 대한 액세스 권한 부여](grant-k8s-access.md) 세션을 참조하세요. **Topics** + [정책 모범 사례](#security-iam-service-with-iam-policy-best-practices) + [Amazon EKS 콘솔 사용](#security-iam-id-based-policy-examples-console) + [IAM 사용자가 자체 권한을 볼 수 있도록 허용](#security-iam-id-based-policy-examples-view-own-permissions) + [AWS Cloud에서 Kubernetes 클러스터 생성](#policy-create-cluster) + [Outpost에서 로컬 Kubernetes 클러스터 생성](#policy-create-local-cluster) + [Kubernetes 클러스터 업데이트](#policy-example1) + [모든 클러스터 나열 또는 설명](#policy-example2) ## 정책 모범 사례 ID 기반 정책에 따라 계정에서 사용자가 Amazon EKS 리소스를 생성, 액세스 또는 삭제할 수 있는지 여부가 결정됩니다. 이 작업으로 인해 AWS 계정에 비용이 발생할 수 있습니다. 자격 증명 기반 정책을 생성하거나 편집할 때는 다음 지침과 권장 사항을 따릅니다. + **AWS 관리형 정책으로 시작하고 최소 권한을 향해 나아가기** - 사용자 및 워크로드에 권한 부여를 시작하려면 많은 일반 사용 사례에 대한 권한을 부여하는 *AWS 관리형 정책*을 사용합니다. AWS 계정에서 사용할 수 있습니다. 사용 사례에 고유한 AWS고객 관리형 정책을 정의하여 권한을 줄이는 것이 좋습니다. 자세한 내용은 *IAM 사용자 설명서*의 [AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) 또는 [AWS직무에 대한 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)을 참조하세요. + **최소 권한 적용** – IAM 정책을 사용하여 권한을 설정하는 경우, 작업을 수행하는 데 필요한 권한만 부여합니다. 이렇게 하려면 *최소 권한*으로 알려진 특정 조건에서 특정 리소스에 대해 수행할 수 있는 작업을 정의합니다. IAM을 사용하여 권한을 적용하는 방법에 대한 자세한 정보는 *IAM 사용자 설명서*에 있는 [IAM의 정책 및 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)을 참조하세요. + **IAM 정책의 조건을 사용하여 액세스 추가 제한** – 정책에 조건을 추가하여 작업 및 리소스에 대한 액세스를 제한할 수 있습니다. 예를 들어, SSL을 사용하여 모든 요청을 전송해야 한다고 지정하는 정책 조건을 작성할 수 있습니다. AWS CloudFormation와 같이, 특정 AWS 서비스를 통해 사용되는 경우에만 서비스 작업에 대한 액세스 권한을 부여할 수도 있습니다. 자세한 내용은 *IAM 사용자 설명서*의 [IAM JSON 정책 요소: 조건](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)을 참조하세요. + **IAM Access Analyzer를 통해 IAM 정책을 확인하여 안전하고 기능적인 권한 보장** - IAM Access Analyzer에서는 IAM 정책 언어(JSON)와 모범 사례가 정책에서 준수되도록 새로운 및 기존 정책을 확인합니다. IAM Access Analyzer는 100개 이상의 정책 확인 항목과 실행 가능한 추천을 제공하여 안전하고 기능적인 정책을 작성하도록 돕습니다. 자세한 정보는 *IAM 사용 설명서*의 [IAM Access Analyzer 정책 검증](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)을 참조하세요. + **다중 인증(MFA) 필요** – AWS 계정에 IAM 사용자 또는 루트 사용자가 필요한 시나리오가 있는 경우, 추가 보안을 위해 MFA를 설정합니다. API 작업을 직접적으로 직접 호출할 때 MFA가 필요하면 정책에 MFA 조건을 추가합니다. 자세한 정보는 *IAM 사용 설명서*의 [MFA 보호 API 액세스 구성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)을 참조하세요. IAM의 모범 사례에 대한 자세한 내용은 *IAM 사용 설명서*의 [IAM의 보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)를 참조하세요. ## Amazon EKS 콘솔 사용 Amazon EKS 콘솔에 액세스하려면 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)는 최소한의 권한 집합이 있어야 합니다. 이러한 권한은 보안 주체가 AWS 계정에서 Amazon EKS 리소스에 대한 세부 정보를 나열하고 볼 수 있도록 허용합니다. 최소 필수 권한보다 더 제한적인 보안 인증 정보 기반 정책을 만들면 콘솔이 해당 정책이 연결된 보안 주체에 대해 의도대로 작동하지 않습니다. 이러한 IAM 보안 주체가 Amazon EKS 콘솔을 계속 사용할 수 있도록 하려면 `AmazonEKSAdminPolicy`와 같은 고유한 자체 이름으로 정책을 생성합니다. 정책을 보안 주체에게 연결하세요. 자세한 정보는 *IAM 사용 설명서*의 [IAM 자격 증명 권한 추가 및 제거](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) 섹션을 참조하세요. **중요** 다음 정책 예를 사용하면 보안 주체는 콘솔의 **구성** 탭에 표시되는 정보를 볼 수 있습니다. AWS Management Console에 있는 **개요**와 **리소스** 탭에서 정보를 보려면 위탁자에게 Kubernetes 권한도 필요합니다. 자세한 내용은 [필수 권한](view-kubernetes-resources.md#view-kubernetes-resources-permissions) 섹션을 참조하세요. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:*" ], "Resource": "*" }, { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "*", "Condition": { "StringEquals": { "iam:PassedToService": "eks.amazonaws.com" } } } ] } ``` AWS CLI 또는 AWS API만 직접 호출하는 보안 주체에는 최소 콘솔 권한을 허용할 필요가 없습니다. 그 대신, 수행하려는 API 작업과 일치하는 작업에만 액세스할 수 있도록 합니다. ## IAM 사용자가 자체 권한을 볼 수 있도록 허용 이 예제는 IAM 사용자가 자신의 사용자 ID에 연결된 인라인 및 관리형 정책을 볼 수 있도록 허용하는 정책을 생성하는 방법을 보여 줍니다. 이 정책에는 콘솔에서 또는 AWS CLI나 AWS API를 사용하여 프로그래밍 방식으로 이 작업을 완료할 수 있는 권한이 포함됩니다. ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` ## AWS Cloud에서 Kubernetes 클러스터 생성 이 예제 정책에는 *us-west-2* AWS 리전에서 *my-cluster*라는 Amazon EKS 클러스터를 생성하는 데 필요한 최소 권한이 포함되어 있습니다. AWS 리전을 클러스터를 생성할 AWS 리전으로 바꿀 수 있습니다. AWS Management Console에 **정책의 작업이 리소스 수준 권한을 지원하지 않으므로 `All resources`를 선택해야 합니다.**라는 경고가 표시되면 무시해도 됩니다. 계정에 이미 *AWSServiceRoleForAmazonEKS* 역할이 있는 경우 정책에서 `iam:CreateServiceLinkedRole` 작업을 제거할 수 있습니다. 계정에 Amazon EKS 클러스터를 생성한 적이 있다면 삭제하지 않는 한 이 역할이 이미 존재합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "eks:CreateCluster", "Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster" }, { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::111122223333:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS", "Condition": { "ForAnyValue:StringEquals": { "iam:AWSServiceName": "eks" } } }, { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::111122223333:role/cluster-role-name" } ] } ``` ## Outpost에서 로컬 Kubernetes 클러스터 생성 이 예제 정책에는 *us-west-2* AWS 리전의 Outposts에서 *my-cluster*라는 Amazon EKS 로컬 클러스터를 만드는 데 필요한 최소 권한이 포함되어 있습니다. AWS 리전을 클러스터를 생성할 AWS 리전으로 바꿀 수 있습니다. AWS Management Console에 **정책의 작업이 리소스 수준 권한을 지원하지 않으므로 `All resources`를 선택해야 합니다.**라는 경고가 표시되면 무시해도 됩니다. 계정에 이미 `AWSServiceRoleForAmazonEKSLocalOutpost` 역할이 있는 경우 정책에서 `iam:CreateServiceLinkedRole` 작업을 제거할 수 있습니다. 계정의 Outpost에 Amazon EKS 로컬 클러스터를 생성한 적이 있다면 삭제하지 않는 한 이 역할이 이미 존재합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "eks:CreateCluster", "Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster" }, { "Action": [ "ec2:DescribeSubnets", "ec2:DescribeVpcs", "iam:GetRole" ], "Resource": "*", "Effect": "Allow" }, { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::111122223333:role/aws-service-role/outposts.eks-local.amazonaws.com/AWSServiceRoleForAmazonEKSLocalOutpost" }, { "Effect": "Allow", "Action": [ "iam:PassRole", "iam:ListAttachedRolePolicies" ], "Resource": "arn:aws:iam::111122223333:role/cluster-role-name" }, { "Action": [ "iam:CreateInstanceProfile", "iam:TagInstanceProfile", "iam:AddRoleToInstanceProfile", "iam:GetInstanceProfile", "iam:DeleteInstanceProfile", "iam:RemoveRoleFromInstanceProfile" ], "Resource": "arn:aws:iam::*:instance-profile/eks-local-*", "Effect": "Allow" } ] } ``` ## Kubernetes 클러스터 업데이트 이 예제 정책에는 us-west-2 AWS 리전에서 *my-cluster*라는 클러스터를 업데이트하는 데 필요한 최소 권한이 포함되어 있습니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "eks:UpdateClusterVersion", "Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster" } ] } ``` ## 모든 클러스터 나열 또는 설명 이 예제 정책에는 계정의 모든 클러스터를 나열하고 설명하는 데 필요한 최소 권한이 포함되어 있습니다. [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)는 `update-kubeconfig` AWS CLI 명령을 사용하기 위해 클러스터를 나열하고 설명할 수 있어야 합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:DescribeCluster", "eks:ListClusters" ], "Resource": "*" } ] } ``` # Amazon EKS에 대해 서비스 연결 역할 사용 Amazon Elastic Kubernetes Service는 AWS ID 및 액세스 관리(IAM) [서비스 연결 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)을 사용합니다. 서비스 연결 역할은 Amazon EKS에 직접 연결된 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 Amazon EKS에서 사전 정의하며 서비스에서 다른 AWS 서비스를 자동으로 직접 호출하기 위해 필요한 모든 권한을 포함합니다. **Topics** + [Amazon EKS 클러스터에 대한 역할 사용](using-service-linked-roles-eks.md) + [Amazon EKS 노드 그룹에 대한 역할 사용](using-service-linked-roles-eks-nodegroups.md) + [Amazon EKS Fargate 프로필에 역할 사용](using-service-linked-roles-eks-fargate.md) + [역할을 사용하여 Amazon EKS에 Kubernetes 클러스터 연결](using-service-linked-roles-eks-connector.md) + [Outpost에서 Amazon EKS 로컬 클러스터에 대한 역할 사용](using-service-linked-roles-eks-outpost.md) + [Amazon EKS 대시보드에 역할 사용](using-service-linked-roles-eks-dashboard.md) # Amazon EKS 클러스터에 대한 역할 사용 Amazon Elastic Kubernetes Service는 AWS ID 및 액세스 관리(IAM) [서비스 연결 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)을 사용합니다. 서비스 연결 역할은 Amazon EKS에 직접 연결된 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 Amazon EKS에서 사전 정의하며 서비스에서 다른 AWS 서비스를 자동으로 호출하기 위해 필요한 모든 권한을 포함합니다. 필요한 권한을 수동으로 추가할 필요가 없으므로 서비스 연결 역할은 Amazon EKS를 더 쉽게 설정할 수 있습니다. Amazon EKS에서 서비스 연결 역할의 권한을 정의하므로 다르게 정의되지 않은 한, Amazon EKS만 해당 역할을 수임할 수 있습니다. 정의된 권한에는 신뢰 정책과 권한 정책이 포함되며 이 권한 정책은 다른 IAM 엔티티에 연결할 수 없습니다. 먼저 관련 리소스를 삭제한 후에만 서비스 연결 역할을 삭제할 수 있습니다. 이렇게 하면 리소스에 대한 액세스 권한을 실수로 삭제할 수 없기 때문에 Amazon EKS 리소스가 보호됩니다. 서비스 연결 역할을 지원하는 기타 서비스에 대한 자세한 내용은 [IAM으로 작업하는 AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾으세요. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 링크가 있는 **예**를 선택합니다. ## Amazon EKS에 대한 서비스 연결 역할 권한 Amazon EKS는 `AWSServiceRoleForAmazonEKS`이라는 서비스 연결 역할을 사용합니다. 이 역할을 통해 Amazon EKS는 계정의 클러스터를 관리할 수 있습니다. 연결된 정책은 이 역할이 네트워크 인터페이스, 보안 그룹, 로그 및 VPC와 같은 리소스를 관리하도록 허용합니다. **참고** `AWSServiceRoleForAmazonEKS` 서비스 연결 역할은 클러스터 생성에 필요한 역할과 다릅니다. 자세한 내용은 [Amazon EKS 클러스터 IAM 역할](cluster-iam-role.md) 섹션을 참조하세요. `AWSServiceRoleForAmazonEKS` 서비스 연결 역할은 역할을 위임하기 위해 다음 서비스를 신뢰합니다. + `eks.amazonaws.com` 역할 권한 정책은 Amazon EKS가 지정된 리소스에서 다음 작업을 완료하도록 허용합니다. + [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html) IAM 엔터티(사용자, 그룹, 역할 등)가 서비스 링크 역할을 생성하고 편집하거나 삭제할 수 있도록 권한을 구성할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)을 참조하세요. ## Amazon EKS에 대한 서비스 연결 역할 생성 서비스 링크 역할은 수동으로 생성할 필요가 없습니다. AWS Management Console, AWS CLI 또는 AWS API에서 클러스터를 생성하면 Amazon EKS에서 서비스 연결 역할이 자동으로 생성됩니다. 이 서비스 연결 역할을 삭제했다가 다시 생성해야 하는 경우 동일한 프로세스를 사용하여 계정에서 역할을 다시 생성할 수 있습니다. 클러스터를 생성할 때 Amazon EKS에서는 서비스 연결 역할을 다시 생성합니다. ## Amazon EKS에 대한 서비스 연결 역할 편집 Amazon EKS에서는 `AWSServiceRoleForAmazonEKS` 서비스 연결 역할을 편집하도록 허용하지 않습니다. 서비스 링크 역할을 생성한 후에는 다양한 개체가 역할을 참조할 수 있기 때문에 역할 이름을 변경할 수 없습니다. 하지만 IAM을 사용하여 역할의 설명을 편집할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 편집](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)을 참조하세요. ## Amazon EKS에 대한 서비스 연결 역할 삭제 서비스 연결 역할이 필요한 기능 또는 서비스가 더 이상 필요 없는 경우에는 해당 역할을 삭제하는 것이 좋습니다. 따라서 적극적으로 모니터링하거나 유지하지 않는 미사용 엔터티가 없도록 합니다. 단, 서비스 연결 역할을 정리해야 수동으로 삭제할 수 있습니다. ### 서비스 연결 역할을 정리 IAM을 사용하여 서비스 연결 역할을 삭제하기 전에 먼저 역할에서 사용되는 리소스를 삭제해야 합니다. **참고** 리소스를 삭제하려고 할 때 Amazon EKS 서비스가 역할을 사용 중이면 삭제에 실패할 수 있습니다. 이 문제가 발생하면 몇 분 기다렸다가 작업을 다시 시도하세요. 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 좌측 탐색 창에서 **클러스터**를 선택합니다. 1. 클러스터에 노드 그룹 또는 Fargate 프로필이 있는 경우 클러스터를 삭제하기 전에 이를 삭제해야 합니다. 자세한 내용을 알아보려면 [클러스터에서 관리형 노드 그룹 삭제](delete-managed-node-group.md) 및 [Fargate 프로필 삭제](delete-fargate-profile.md) 섹션을 참조하세요. 1. **클러스터** 페이지에서 삭제하려는 클러스터를 선택하고 **삭제**를 선택합니다. 1. 삭제 확인 창에 클러스터 이름을 입력한 다음 **삭제**를 선택합니다. 1. 계정의 다른 클러스터에 대해 이 절차를 반복합니다. 모든 삭제 작업이 완료될 때까지 기다립니다. ### 수동으로 서비스 연결 역할 삭제 IAM 콘솔, AWS CLI 또는 AWS API를 사용하여 `AWSServiceRoleForAmazonEKS` 서비스 연결 역할을 삭제합니다. 자세한 내용은 IAM 사용 설명서의 [서비스에 연결 역할 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)**를 참조하세요. ## Amazon EKS 서비스 연결 역할을 지원하는 리전 Amazon EKS는 서비스가 제공되는 모든 리전에서 서비스 연결 역할 사용을 지원합니다. 자세한 내용을 알아보려면 [Amazon EKS 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/eks.html)을 참조하세요. # Amazon EKS 노드 그룹에 대한 역할 사용 Amazon EKS는 AWS ID 및 액세스 관리(IAM) [service-linked 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)을 사용합니다. 서비스 연결 역할은 Amazon EKS에 직접 연결된 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 Amazon EKS에서 사전 정의하며 서비스에서 다른 AWS 서비스를 자동으로 호출하기 위해 필요한 모든 권한을 포함합니다. 필요한 권한을 수동으로 추가할 필요가 없으므로 서비스 연결 역할은 Amazon EKS를 더 쉽게 설정할 수 있습니다. Amazon EKS에서 서비스 연결 역할의 권한을 정의하므로 다르게 정의되지 않은 한, Amazon EKS만 해당 역할을 수임할 수 있습니다. 정의된 권한에는 신뢰 정책과 권한 정책이 포함되며 이 권한 정책은 다른 IAM 엔티티에 연결할 수 없습니다. 먼저 관련 리소스를 삭제한 후에만 서비스 연결 역할을 삭제할 수 있습니다. 이렇게 하면 리소스에 대한 액세스 권한을 실수로 삭제할 수 없기 때문에 Amazon EKS 리소스가 보호됩니다. 서비스 연결 역할을 지원하는 기타 서비스에 대한 자세한 내용은 [IAM으로 작업하는 AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾으세요. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 링크가 있는 **예**를 선택합니다. ## Amazon EKS에 대한 서비스 연결 역할 권한 Amazon EKS는 `AWSServiceRoleForAmazonEKSNodegroup`이라는 서비스 연결 역할을 사용합니다. 이 역할을 통해 Amazon EKS는 계정의 노드 그룹을 관리할 수 있습니다. 연결된 `AWSServiceRoleForAmazonEKSNodegroup` 정책은 이 역할이 Auto Scaling 그룹, 보안 그룹, 시작 템플릿, IAM 인스턴스 프로파일 등의 리소스를 관리하도록 허용합니다. 자세한 내용은 [AWS 관리형 정책: AWSServiceRoleForAmazonEKSNodegroup](security-iam-awsmanpol.md#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) 단원을 참조하십시오. `AWSServiceRoleForAmazonEKSNodegroup` 서비스 연결 역할은 역할을 위임하기 위해 다음 서비스를 신뢰합니다. + `eks-nodegroup.amazonaws.com` 역할 권한 정책은 Amazon EKS가 지정된 리소스에서 다음 작업을 완료하도록 허용합니다. + [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html) IAM 엔터티(사용자, 그룹, 역할 등)가 서비스 링크 역할을 생성하고 편집하거나 삭제할 수 있도록 권한을 구성할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)을 참조하세요. ## Amazon EKS에 대한 서비스 연결 역할 생성 서비스 링크 역할은 수동으로 생성할 필요가 없습니다. AWS Management Console, AWS CLI 또는 AWS API에서 관리형 노드 그룹을 생성하면 Amazon EKS에서 서비스 연결 역할이 자동으로 생성됩니다. **중요** 이러한 서비스 연결 역할은 해당 역할이 지원하는 기능을 사용하는 다른 서비스에서 작업을 완료했을 경우 계정에 나타날 수 있습니다. Amazon EKS 서비스가 서비스 연결 역할을 지원하기 시작한 2017년 1월 1일 이전에 이 서비스를 사용했다면 Amazon EKS가 사용자 계정에 AWSServiceRoleForAmazonEKSNodegroup 역할을 이미 생성했습니다. 자세한 내용은 [내 IAM 계정에 표시되는 새 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)을 참조하세요. ### Amazon EKS(AWS API)에서 서비스 연결 역할 생성 서비스 링크 역할은 수동으로 생성할 필요가 없습니다. AWS Management Console, AWS CLI 또는 AWS API에서 관리형 노드 그룹을 생성하면 Amazon EKS에서 서비스 연결 역할이 자동으로 생성됩니다. 이 서비스 연결 역할을 삭제했다가 다시 생성해야 하는 경우 동일한 프로세스를 사용하여 계정에서 역할을 다시 생성할 수 있습니다. 다른 관리형 노드 그룹을 생성할 때 Amazon EKS가 서비스 연결 역할을 다시 생성합니다. ## Amazon EKS에 대한 서비스 연결 역할 편집 Amazon EKS에서는 `AWSServiceRoleForAmazonEKSNodegroup` 서비스 연결 역할을 편집하도록 허용하지 않습니다. 서비스 링크 역할을 생성한 후에는 다양한 개체가 역할을 참조할 수 있기 때문에 역할 이름을 변경할 수 없습니다. 하지만 IAM을 사용하여 역할의 설명을 편집할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 편집](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)을 참조하세요. ## Amazon EKS에 대한 서비스 연결 역할 삭제 서비스 연결 역할이 필요한 기능 또는 서비스가 더 이상 필요 없는 경우에는 해당 역할을 삭제하는 것이 좋습니다. 따라서 적극적으로 모니터링하거나 유지하지 않는 미사용 엔터티가 없도록 합니다. 단, 서비스 연결 역할을 정리해야 수동으로 삭제할 수 있습니다. ### 서비스 연결 역할을 정리 IAM을 사용하여 서비스 연결 역할을 삭제하기 전에 먼저 역할에서 사용되는 리소스를 삭제해야 합니다. **참고** 리소스를 삭제하려고 할 때 Amazon EKS 서비스가 역할을 사용 중이면 삭제에 실패할 수 있습니다. 이 문제가 발생하면 몇 분 기다렸다가 작업을 다시 시도하세요. 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 좌측 탐색 창에서 **클러스터**를 선택합니다. 1. **컴퓨팅** 탭을 선택합니다. 1. **노드 그룹** 섹션에서 삭제할 노드 그룹을 선택합니다. 1. 삭제 확인 창에 노드 그룹 이름을 입력한 다음 **삭제**를 선택합니다. 1. 클러스터의 다른 노드 그룹에 대해 이 절차를 반복합니다. 모든 삭제 작업이 완료될 때까지 기다립니다. ### 수동으로 서비스 연결 역할 삭제 IAM 콘솔, AWS CLI 또는 AWS API를 사용하여 `AWSServiceRoleForAmazonEKSNodegroup` 서비스 연결 역할을 삭제합니다. 자세한 내용은 IAM 사용 설명서의 [서비스에 연결 역할 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)**를 참조하세요. ## Amazon EKS 서비스 연결 역할을 지원하는 리전 Amazon EKS는 서비스가 제공되는 모든 리전에서 서비스 연결 역할 사용을 지원합니다. 자세한 내용을 알아보려면 [Amazon EKS 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/eks.html)을 참조하세요. # Amazon EKS Fargate 프로필에 역할 사용 Amazon EKS는 AWS ID 및 액세스 관리(IAM) [service-linked 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)을 사용합니다. 서비스 연결 역할은 Amazon EKS에 직접 연결된 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 Amazon EKS에서 사전 정의하며 서비스에서 다른 AWS 서비스를 자동으로 호출하기 위해 필요한 모든 권한을 포함합니다. 필요한 권한을 수동으로 추가할 필요가 없으므로 서비스 연결 역할은 Amazon EKS를 더 쉽게 설정할 수 있습니다. Amazon EKS에서 서비스 연결 역할의 권한을 정의하므로 다르게 정의되지 않은 한, Amazon EKS만 해당 역할을 수임할 수 있습니다. 정의된 권한에는 신뢰 정책과 권한 정책이 포함되며 이 권한 정책은 다른 IAM 엔티티에 연결할 수 없습니다. 먼저 관련 리소스를 삭제한 후에만 서비스 연결 역할을 삭제할 수 있습니다. 이렇게 하면 리소스에 대한 액세스 권한을 실수로 삭제할 수 없기 때문에 Amazon EKS 리소스가 보호됩니다. 서비스 연결 역할을 지원하는 기타 서비스에 대한 자세한 내용은 [IAM으로 작업하는 AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾으세요. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 링크가 있는 **예**를 선택합니다. ## Amazon EKS에 대한 서비스 연결 역할 권한 Amazon EKS는 `AWSServiceRoleForAmazonEKSForFargate`이라는 서비스 연결 역할을 사용합니다. 이 역할을 통해 Amazon EKS Fargate는 Fargate 포드에 필요한 VPC 네트워킹을 구성할 수 있습니다. 연결된 정책을 통해 역할은 탄력적 네트워크 인터페이스를 생성 및 삭제하고 탄력적 네트워크 인터페이스 및 리소스를 설명할 수 있습니다. `AWSServiceRoleForAmazonEKSForFargate` 서비스 연결 역할은 역할을 수임하기 위해 다음 서비스를 신뢰합니다. + `eks-fargate.amazonaws.com` 역할 권한 정책은 Amazon EKS가 지정된 리소스에서 다음 작업을 완료하도록 허용합니다. + [AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html) IAM 엔터티(사용자, 그룹, 역할 등)가 서비스 링크 역할을 생성하고 편집하거나 삭제할 수 있도록 권한을 구성할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)을 참조하세요. ## Amazon EKS에 대한 서비스 연결 역할 생성 서비스 링크 역할은 수동으로 생성할 필요가 없습니다. AWS Management Console, AWS CLI 또는 AWS API에서 Fargate 프로필을 생성하면 Amazon EKS에서 서비스 연결 역할이 자동으로 생성됩니다. **중요** 이러한 서비스 연결 역할은 해당 역할이 지원하는 기능을 사용하는 다른 서비스에서 작업을 완료했을 경우 계정에 나타날 수 있습니다. Amazon EKS 서비스가 서비스 연결 역할을 지원하기 시작한 2019년 12월 13일 이전에 이 서비스를 사용했다면 Amazon EKS가 사용자 계정에 AWSServiceRoleForAmazonEKSForFargate 역할을 이미 생성했습니다. 자세한 내용을 알아보려면 [내 IAM 계정에 표시되는 새 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)을 참조하세요. ### Amazon EKS(AWS API)에서 서비스 연결 역할 생성 서비스 링크 역할은 수동으로 생성할 필요가 없습니다. AWS Management Console, AWS CLI 또는 AWS API에서 Fargate 프로필을 생성하면 Amazon EKS에서 서비스 연결 역할이 자동으로 생성됩니다. 이 서비스 연결 역할을 삭제했다가 다시 생성해야 하는 경우 동일한 프로세스를 사용하여 계정에서 역할을 다시 생성할 수 있습니다. 다른 관리형 노드 그룹을 생성할 때 Amazon EKS가 서비스 연결 역할을 다시 생성합니다. ## Amazon EKS에 대한 서비스 연결 역할 편집 Amazon EKS에서는 `AWSServiceRoleForAmazonEKSForFargate` 서비스 연결 역할을 편집하도록 허용하지 않습니다. 서비스 링크 역할을 생성한 후에는 다양한 개체가 역할을 참조할 수 있기 때문에 역할 이름을 변경할 수 없습니다. 하지만 IAM을 사용하여 역할의 설명을 편집할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 편집](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)을 참조하세요. ## Amazon EKS에 대한 서비스 연결 역할 삭제 서비스 연결 역할이 필요한 기능 또는 서비스가 더 이상 필요 없는 경우에는 해당 역할을 삭제하는 것이 좋습니다. 따라서 적극적으로 모니터링하거나 유지하지 않는 미사용 엔터티가 없도록 합니다. 단, 서비스 연결 역할을 정리해야 수동으로 삭제할 수 있습니다. ### 서비스 연결 역할을 정리 IAM을 사용하여 서비스 연결 역할을 삭제하기 전에 먼저 역할에서 사용되는 리소스를 삭제해야 합니다. **참고** 리소스를 삭제하려고 할 때 Amazon EKS 서비스가 역할을 사용 중이면 삭제에 실패할 수 있습니다. 이 문제가 발생하면 몇 분 기다렸다가 작업을 다시 시도하세요. 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 좌측 탐색 창에서 **클러스터**를 선택합니다. 1. **클러스터** 페이지에서 클러스터를 선택합니다. 1. **컴퓨팅** 탭을 선택합니다. 1. **Fargate 프로필** 섹션에 Fargate 프로필이 있는 경우 각각 개별적으로 선택한 다음 **삭제**를 선택합니다. 1. 삭제 확인 창에 프로필 이름을 입력한 다음 **삭제**를 선택합니다. 1. 클러스터의 다른 Fargate 프로필과 계정의 다른 클러스터에 대해 이 절차를 반복합니다. ### 수동으로 서비스 연결 역할 삭제 IAM 콘솔, AWS CLI 또는 AWS API를 사용하여 AWSServiceRoleForAmazonEKSForFargate 서비스 연결 역할을 삭제합니다. 자세한 내용은 IAM 사용 설명서의 [서비스에 연결 역할 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)**를 참조하세요. ## Amazon EKS 서비스 연결 역할을 지원하는 리전 Amazon EKS는 서비스가 제공되는 모든 리전에서 서비스 연결 역할 사용을 지원합니다. 자세한 내용을 알아보려면 [Amazon EKS 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/eks.html)을 참조하세요. # 역할을 사용하여 Amazon EKS에 Kubernetes 클러스터 연결 Amazon EKS는 AWS ID 및 액세스 관리(IAM) [service-linked 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)을 사용합니다. 서비스 연결 역할은 Amazon EKS에 직접 연결된 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 Amazon EKS에서 사전 정의하며 서비스에서 다른 AWS 서비스를 자동으로 직접 호출하기 위해 필요한 모든 권한을 포함합니다. 필요한 권한을 수동으로 추가할 필요가 없으므로 서비스 연결 역할은 Amazon EKS를 더 쉽게 설정할 수 있습니다. Amazon EKS에서 서비스 연결 역할의 권한을 정의하므로 다르게 정의되지 않은 한, Amazon EKS만 해당 역할을 수임할 수 있습니다. 정의된 권한에는 신뢰 정책과 권한 정책이 포함되며 이 권한 정책은 다른 IAM 엔터티에 연결할 수 없습니다. 먼저 관련 리소스를 삭제한 후에만 서비스 연결 역할을 삭제할 수 있습니다. 이렇게 하면 리소스에 대한 액세스 권한을 실수로 삭제할 수 없기 때문에 Amazon EKS 리소스가 보호됩니다. 서비스 연결 역할을 지원하는 기타 서비스에 대한 자세한 내용은 [IAM으로 작업하는 AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾으세요. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 **예(Yes)** 링크를 선택합니다. ## Amazon EKS에 대한 서비스 연결 역할 권한 Amazon EKS는 `AWSServiceRoleForAmazonEKSConnector`이라는 서비스 연결 역할을 사용합니다. 이 역할을 통해 Amazon EKS는 Kubernetes 클러스터를 연결할 수 있습니다. 연결된 정책을 사용하면 역할이 등록된 Kubernetes 클러스터에 연결하는 데 필요한 리소스를 관리할 수 있습니다. `AWSServiceRoleForAmazonEKSConnector` 서비스 연결 역할은 역할을 수임하기 위해 다음 서비스를 신뢰합니다. + `eks-connector.amazonaws.com` 역할 권한 정책은 Amazon EKS가 지정된 리소스에서 다음 작업을 완료하도록 허용합니다. + [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html) IAM 엔터티(사용자, 그룹, 역할 등)가 서비스 연결 역할을 생성하고 편집하거나 삭제할 수 있도록 권한을 구성할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) 섹션을 참조하세요. 이 역할은 SSM(Systems Manager) 권한을 사용하여 보안 연결을 설정하고 연결된 Kubernetes 클러스터를 관리합니다. ## Amazon EKS에 대한 서비스 연결 역할 생성 클러스터 연결을 위해 서비스 연결 역할을 수동으로 생성할 필요가 없습니다. AWS Management Console, AWS CLI, `eksctl` 또는 AWS API에서 클러스터를 연결하면 Amazon EKS에서 서비스 연결 역할이 자동으로 생성됩니다. 이 서비스 연결 역할을 삭제했다가 다시 생성해야 하는 경우 동일한 프로세스를 사용하여 계정에서 역할을 다시 생성할 수 있습니다. 클러스터를 연결할 때 Amazon EKS에서는 서비스 연결 역할을 다시 생성합니다. ## Amazon EKS에 대한 서비스 연결 역할 편집 Amazon EKS에서는 `AWSServiceRoleForAmazonEKSConnector` 서비스 연결 역할을 편집하도록 허용하지 않습니다. 서비스 연결 역할을 생성한 후에는 다양한 개체가 역할을 참조할 수 있기 때문에 역할 이름을 변경할 수 없습니다. 하지만 IAM을 사용하여 역할의 설명을 편집할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 편집](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)을 참조하세요. ## Amazon EKS에 대한 서비스 연결 역할 삭제 서비스 연결 역할이 필요한 기능 또는 서비스가 더 이상 필요 없는 경우에는 해당 역할을 삭제하는 것이 좋습니다. 따라서 적극적으로 모니터링하거나 유지하지 않는 미사용 엔터티가 없도록 합니다. 단, 서비스 연결 역할을 정리해야 수동으로 삭제할 수 있습니다. ### 서비스 연결 역할을 정리 IAM을 사용하여 서비스 연결 역할을 삭제하기 전에 먼저 역할에서 사용되는 리소스를 삭제해야 합니다. **참고** 리소스를 삭제하려고 할 때 Amazon EKS 서비스가 역할을 사용 중이면 삭제에 실패할 수 있습니다. 이 문제가 발생하면 몇 분 기다렸다가 작업을 다시 시도하세요. 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 좌측 탐색 창에서 **클러스터**를 선택합니다. 1. **클러스터** 페이지에서 클러스터를 선택합니다. 1. **등록 취소** 탭을 선택한 다음 **확인** 탭을 선택합니다. ### 수동으로 서비스 연결 역할 삭제 IAM 콘솔, AWS CLI 또는 AWS API를 사용하여 AWSServiceRoleForAmazonEKSConnector 서비스 연결 역할을 삭제합니다. 자세한 내용은 IAM 사용 설명서의 [서비스에 연결 역할 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)**를 참조하세요. # Outpost에서 Amazon EKS 로컬 클러스터에 대한 역할 사용 Amazon Elastic Kubernetes Service는 AWS ID 및 액세스 관리(IAM) [서비스 연결 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)을 사용합니다. 서비스 연결 역할은 Amazon EKS에 직접 연결된 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 Amazon EKS에서 사전 정의하며 서비스에서 다른 AWS 서비스를 자동으로 호출하기 위해 필요한 모든 권한을 포함합니다. 필요한 권한을 수동으로 추가할 필요가 없으므로 서비스 연결 역할은 Amazon EKS를 더 쉽게 설정할 수 있습니다. Amazon EKS에서 서비스 연결 역할의 권한을 정의하므로 다르게 정의되지 않은 한, Amazon EKS만 해당 역할을 수임할 수 있습니다. 정의된 권한에는 신뢰 정책과 권한 정책이 포함되며 이 권한 정책은 다른 IAM 엔티티에 연결할 수 없습니다. 먼저 관련 리소스를 삭제한 후에만 서비스 연결 역할을 삭제할 수 있습니다. 이렇게 하면 리소스에 대한 액세스 권한을 실수로 삭제할 수 없기 때문에 Amazon EKS 리소스가 보호됩니다. 서비스 연결 역할을 지원하는 기타 서비스에 대한 자세한 내용은 [IAM으로 작업하는 AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾으세요. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 링크가 있는 **예**를 선택합니다. ## Amazon EKS에 대한 서비스 연결 역할 권한 Amazon EKS는 `AWSServiceRoleForAmazonEKSLocalOutpost`이라는 서비스 연결 역할을 사용합니다. 이 역할을 통해 Amazon EKS는 계정의 로컬 클러스터를 관리할 수 있습니다. 연결된 정책은 이 역할이 네트워크 인터페이스, 보안 그룹, 로그 및 Amazon EC2 인스턴스와 같은 리소스를 관리하도록 허용합니다. **참고** `AWSServiceRoleForAmazonEKSLocalOutpost` 서비스 연결 역할은 클러스터 생성에 필요한 역할과 다릅니다. 자세한 내용은 [Amazon EKS 클러스터 IAM 역할](cluster-iam-role.md) 섹션을 참조하세요. `AWSServiceRoleForAmazonEKSLocalOutpost` 서비스 연결 역할은 역할을 위임하기 위해 다음 서비스를 신뢰합니다. + `outposts.eks-local.amazonaws.com` 역할 권한 정책은 Amazon EKS가 지정된 리소스에서 다음 작업을 완료하도록 허용합니다. + [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html) IAM 엔터티(사용자, 그룹, 역할 등)가 서비스 링크 역할을 생성하고 편집하거나 삭제할 수 있도록 권한을 구성할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)을 참조하세요. ## Amazon EKS에 대한 서비스 연결 역할 생성 서비스 링크 역할은 수동으로 생성할 필요가 없습니다. AWS Management Console, AWS CLI 또는 AWS API에서 클러스터를 생성하면 Amazon EKS에서 서비스 연결 역할이 자동으로 생성됩니다. 이 서비스 연결 역할을 삭제했다가 다시 생성해야 하는 경우 동일한 프로세스를 사용하여 계정에서 역할을 다시 생성할 수 있습니다. 클러스터를 생성할 때 Amazon EKS에서는 서비스 연결 역할을 다시 생성합니다. ## Amazon EKS에 대한 서비스 연결 역할 편집 Amazon EKS에서는 `AWSServiceRoleForAmazonEKSLocalOutpost` 서비스 연결 역할을 편집하도록 허용하지 않습니다. 서비스 연결 역할을 생성한 후에는 다양한 엔터티가 역할을 참조할 수 있기 때문에 역할 이름을 변경할 수 없습니다. 하지만 IAM을 사용하여 역할의 설명을 편집할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 편집](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)을 참조하세요. ## Amazon EKS에 대한 서비스 연결 역할 삭제 서비스 연결 역할이 필요한 기능 또는 서비스가 더 이상 필요 없는 경우에는 해당 역할을 삭제하는 것이 좋습니다. 따라서 적극적으로 모니터링하거나 유지하지 않는 미사용 엔터티가 없도록 합니다. 단, 서비스 연결 역할을 정리해야 수동으로 삭제할 수 있습니다. ### 서비스 연결 역할을 정리 IAM을 사용하여 서비스 연결 역할을 삭제하기 전에 먼저 역할에서 사용되는 리소스를 삭제해야 합니다. **참고** 리소스를 삭제하려고 할 때 Amazon EKS 서비스가 역할을 사용 중이면 삭제에 실패할 수 있습니다. 이 문제가 발생하면 몇 분 기다렸다가 작업을 다시 시도하세요. 1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다. 1. 왼쪽 탐색 창에서 Amazon EKS **클러스터**를 선택합니다. 1. 클러스터에 노드 그룹 또는 Fargate 프로필이 있는 경우 클러스터를 삭제하기 전에 이를 삭제해야 합니다. 자세한 내용을 알아보려면 [클러스터에서 관리형 노드 그룹 삭제](delete-managed-node-group.md) 및 [Fargate 프로필 삭제](delete-fargate-profile.md) 섹션을 참조하세요. 1. **클러스터** 페이지에서 삭제하려는 클러스터를 선택하고 **삭제**를 선택합니다. 1. 삭제 확인 창에 클러스터 이름을 입력한 다음 **삭제**를 선택합니다. 1. 계정의 다른 클러스터에 대해 이 절차를 반복합니다. 모든 삭제 작업이 완료될 때까지 기다립니다. ### 수동으로 서비스 연결 역할 삭제 IAM 콘솔, AWS CLI 또는 AWS API를 사용하여 `AWSServiceRoleForAmazonEKSLocalOutpost` 서비스 연결 역할을 삭제합니다. 자세한 내용은 IAM 사용 설명서의 [서비스에 연결 역할 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)**를 참조하세요. ## Amazon EKS 서비스 연결 역할을 지원하는 리전 Amazon EKS는 서비스가 제공되는 모든 리전에서 서비스 연결 역할 사용을 지원합니다. 자세한 내용을 알아보려면 [Amazon EKS 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/eks.html)을 참조하세요. # Amazon EKS 대시보드에 역할 사용 Amazon EKS 대시보드는 이 서비스 연결 역할을 사용하여 여러 리전 및 계정의 클러스터 리소스에 대한 정보를 집계합니다. 대시보드는 AWS Organizations와 통합되어 조직의 여러 계정에 대한 정보를 안전하게 읽습니다. Amazon EKS 대시보드에 대한 자세한 내용은 [EKS 대시보드를 사용하여 클러스터 리소스에 대한 집계된 데이터 보기](cluster-dashboard.md) 섹션을 참조하세요. ## 배경 Amazon EKS는 AWS ID 및 액세스 관리(IAM) [service-linked 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)을 사용합니다. 서비스 연결 역할은 Amazon EKS에 직접 연결된 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 Amazon EKS에서 사전 정의하며 서비스에서 다른 AWS 서비스를 자동으로 직접 호출하기 위해 필요한 모든 권한을 포함합니다. 필요한 권한을 수동으로 추가할 필요가 없으므로 서비스 연결 역할은 Amazon EKS를 더 쉽게 설정할 수 있습니다. Amazon EKS에서 서비스 연결 역할의 권한을 정의하므로 다르게 정의되지 않은 한, Amazon EKS만 해당 역할을 수임할 수 있습니다. 정의된 권한에는 신뢰 정책과 권한 정책이 포함되며 이 권한 정책은 다른 IAM 엔티티에 연결할 수 없습니다. 먼저 관련 리소스를 삭제한 후에만 서비스 연결 역할을 삭제할 수 있습니다. 이렇게 하면 리소스에 대한 액세스 권한을 실수로 삭제할 수 없기 때문에 Amazon EKS 리소스가 보호됩니다. 서비스 연결 역할을 지원하는 기타 서비스에 대한 자세한 내용은 [IAM으로 작업하는 AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾으세요. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 링크가 있는 **예**를 선택합니다. ## Amazon EKS에 대한 서비스 연결 역할 권한 Amazon EKS는 `AWSServiceRoleForAmazonEKSDashboard`이라는 서비스 연결 역할을 사용합니다. 이 역할을 통해 Amazon EKS는 클러스터 리소스에 대한 집계된 정보를 포함하여 EKS 대시보드를 생성하고 표시할 수 있습니다. 연결된 `AmazonEKSDashboardServiceRolePolicy` 정책은 이 역할이 Auto Scaling 그룹, 보안 그룹, 시작 템플릿, IAM 인스턴스 프로파일 등의 리소스를 관리하도록 허용합니다. 자세한 내용은 [AWS 관리형 정책: AmazonEKSDashboardServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy) 섹션을 참조하세요. `AWSServiceRoleForAmazonEKSDashboard` 서비스 연결 역할은 역할을 위임하기 위해 다음 서비스를 신뢰합니다. + `dashboard.eks.amazonaws.com` 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json)를 참조하세요. IAM 엔터티(사용자, 그룹, 역할 등)가 서비스 링크 역할을 생성하고 편집하거나 삭제할 수 있도록 권한을 구성할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)을 참조하세요. ## Amazon EKS에 대한 서비스 연결 역할 생성 서비스 링크 역할은 수동으로 생성할 필요가 없습니다. AWS 콘솔에서 대시보드를 활성화하면 Amazon EKS가 서비스 연결 역할을 생성합니다. EKS 대시보드 활성화에 대한 자세한 내용은 [AWS Organizations와의 EKS 대시보드 통합 구성](cluster-dashboard-orgs.md) 섹션을 참조하세요. **중요** 이러한 서비스 연결 역할은 해당 역할이 지원하는 기능을 사용하는 다른 서비스에서 작업을 완료했을 경우 계정에 나타날 수 있습니다. ## Amazon EKS에 대한 서비스 연결 역할 편집 Amazon EKS에서는 `AWSServiceRoleForAmazonEKSDashboard` 서비스 연결 역할을 편집하도록 허용하지 않습니다. 서비스 링크 역할을 생성한 후에는 다양한 개체가 역할을 참조할 수 있기 때문에 역할 이름을 변경할 수 없습니다. 하지만 IAM을 사용하여 역할의 설명을 편집할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 편집](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)을 참조하세요. ## Amazon EKS에 대한 서비스 연결 역할 삭제 서비스 연결 역할이 필요한 기능 또는 서비스가 더 이상 필요 없는 경우에는 해당 역할을 삭제하는 것이 좋습니다. 따라서 적극적으로 모니터링하거나 유지하지 않는 미사용 엔터티가 없도록 합니다. 단, 서비스 연결 역할을 정리해야 수동으로 삭제할 수 있습니다. ### 서비스 연결 역할을 정리 IAM을 사용하여 서비스 연결 역할을 삭제하기 전에 먼저 역할에서 사용되는 리소스를 삭제해야 합니다. **참고** 리소스를 삭제하려고 할 때 Amazon EKS 서비스가 역할을 사용 중이면 삭제에 실패할 수 있습니다. 이 문제가 발생하면 몇 분 기다렸다가 작업을 다시 시도하세요. EKS 대시보드 비활성화에 대한 자세한 내용은 [AWS Organizations와의 EKS 대시보드 통합 구성](cluster-dashboard-orgs.md) 섹션을 참조하세요. ### 수동으로 서비스 연결 역할 삭제 IAM 콘솔, AWS CLI 또는 AWS API를 사용하여 `AWSServiceRoleForAmazonEKSDashboard` 서비스 연결 역할을 삭제합니다. 자세한 내용은 IAM 사용 설명서의 [서비스에 연결 역할 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)**를 참조하세요. ## Amazon EKS 서비스 연결 역할을 지원하는 리전 Amazon EKS는 서비스가 제공되는 모든 리전에서 서비스 연결 역할 사용을 지원합니다. 자세한 내용을 알아보려면 [Amazon EKS 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/eks.html)을 참조하세요. # Amazon EKS 포드 실행 IAM 역할 AWS Fargate 인프라에서 포드를 실행하려면 Amazon EKS 포드 실행 역할이 필요합니다. 클러스터가 AWS Fargate 인프라에서 포드를 생성하는 경우 Fargate 인프라에서 실행되는 구성 요소는 사용자를 대신하여 AWS API를 직접적으로 직접 호출해야 합니다. 이를 통해 Amazon ECR에서 컨테이너 이미지를 가져오거나 로그를 다른 AWS 서버로 라우팅하는 등의 작업을 수행할 수 있습니다. Amazon EKS 포드 실행 역할은 이 작업을 수행할 수 있는 IAM 권한을 제공합니다. Fargate 프로필을 생성할 때 프로필을 사용하여 Fargate 인프라에서 실행되는 Amazon EKS 구성 요소의 포드 실행 역할을 지정해야 합니다. 이 역할은 권한 부여를 위해 클러스터의 Kubernetes [역할 기반 액세스 제어](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)(RBAC)에 추가됩니다. 이렇게 하면 Fargate 인프라에서 실행 중인 `kubelet`이 Amazon EKS 클러스터에 등록되어 클러스터에 노드로 표시될 수 있습니다. **참고** Fargate 프로필에는 Amazon EC2 노드 그룹과 다른 IAM 역할이 있어야 합니다. **중요** Fargate 포드에서 실행 중인 컨테이너는 포드 실행 역할과 연결된 IAM 권한을 수임할 수 없습니다. Fargate 포드의 컨테이너에 다른 AWS 서비스에 대한 액세스 권한을 부여하려면 [서비스 계정에 IAM 역할](iam-roles-for-service-accounts.md)을 사용해야 합니다. Fargate 프로필을 생성하기 전에 [AmazonEKSFargatePodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html)를 사용하여 IAM 역할을 생성해야 합니다. ## 올바로 구성된 기존 포드 실행 역할 확인 다음 절차를 사용하여 계정에 이미 올바로 구성된 Amazon EKS 포드 실행 역할이 있는지 확인할 수 있습니다. 대리인 보안 문제의 혼동을 방지하려면 역할이 `SourceArn`에 따라 액세스를 제한하는 것이 중요합니다. 필요에 따라 실행 역할을 수정하여 다른 클러스터의 Fargate 프로필에 대한 지원을 포함할 수 있습니다. 1. IAM 콘솔(https://console.aws.amazon.com/iam/)을 엽니다. 1. 왼쪽 탐색 창에서 **역할**을 선택합니다. 1. **역할** 페이지에서 **AmazonEKSFargatePodExecutionRole**에 대한 역할 목록을 검색합니다. 역할이 존재하지 않을 경우 [Amazon EKS 포드 실행 역할 생성](#create-pod-execution-role)을 참조하여 역할을 생성합니다. 역할이 존재하지 않을 경우 역할을 선택합니다. 1. **AmazonEKSFargatePodExecutionRole** 페이지에서 다음을 수행합니다. 1. **권한**을 선택합니다. 1. **AmazonEKSFargatePodExecutionRolePolicy** Amazon 관리형 정책이 역할에 연결되어 있는지 확인합니다. 1. **신뢰 관계**를 선택합니다. 1. **신뢰 정책 편집**을 선택합니다. 1. **신뢰 정책 편집** 페이지에서 신뢰 관계에 다음 정책이 포함되어 있고 클러스터의 Fargate 프로필에 대한 줄이 있는지 확인합니다. 그렇다면 **취소**를 선택합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*" } }, "Principal": { "Service": "eks-fargate-pods.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 정책이 일치하지만 클러스터의 Fargate 프로필을 지정하는 줄이 없는 경우 다음 줄을 `ArnLike` 객체의 상단에 추가할 수 있습니다. *region-code*를 클러스터가 있는 AWS 리전으로 바꾸고 *111122223333*을 계정 ID로 바꾸며 *my-cluster*를 클러스터 이름으로 바꿉니다. ``` "aws:SourceArn": "arn:aws:eks:region-code:111122223333:fargateprofile/my-cluster/*", ``` 정책이 일치하지 않는 경우 이전 정책 전체를 양식에 복사하고 **업데이트 정책**을 선택합니다. *region-code*를 클러스터가 있는 AWS 리전으로 바꿉니다. 계정의 모든 AWS 리전에서 동일한 역할을 사용하려면 *region-code*를 `*`로 바꾸세요. *my\$1cluster*를 실제 클러스터의 이름으로 바꾸고 *111122223333*을 계정 ID로 바꿉니다. 계정의 모든 클러스터에 대해 동일한 역할을 사용하려는 경우 *my-cluster*를 `*`로 바꾸세요. ## Amazon EKS 포드 실행 역할 생성 클러스터에 대한 Amazon EKS 포드 실행 역할이 아직 없는 경우 AWS Management Console 또는 AWS CLI를 사용하여 생성할 수 있습니다. AWS Management Console 1. IAM 콘솔(https://console.aws.amazon.com/iam/)을 엽니다. 1. 왼쪽 탐색 창에서 **역할**을 선택합니다. 1. **역할** 페이지에서 **역할 생성**을 선택합니다. 1. **신뢰할 수 있는 엔터티 선택** 페이지에서 다음을 수행합니다. 1. **신뢰할 수 있는 엔터티 유형** 섹션에서 **AWS 서비스**를 선택합니다. 1. **다른 AWS 서비스의 사용 사례** 드롭다운 목록에서 **EKS**를 선택합니다. 1. **EKS - Fargate 포드**를 선택합니다. 1. **다음**을 선택합니다. 1. **권한 추가** 페이지에서 **다음**을 선택합니다. 1. **이름, 검토 및 생성** 페이지에서 다음을 수행합니다. 1. **역할 이름**에 역할의 고유한 이름(예: `AmazonEKSFargatePodExecutionRole`)을 입력합니다. 1. **태그 추가(선택사항)**에서 태그를 키-값 페어로 연결하여 메타데이터를 역할에 추가합니다. IAM에서 태그 사용에 대한 자세한 내용을 알아보려면 IAM 사용 설명서의 [IAM 리소스에 태깅](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)을 참조하세요. 1. **역할 생성**을 선택합니다. 1. **역할** 페이지에서 **AmazonEKSFargatePodExecutionRole**에 대한 역할 목록을 검색합니다. 역할을 선택합니다. 1. **AmazonEKSFargatePodExecutionRole** 페이지에서 다음을 수행합니다. 1. **신뢰 관계**를 선택합니다. 1. **신뢰 정책 편집**을 선택합니다. 1. **신뢰 정책 편집** 페이지에서 다음 작업을 수행합니다. 1. 다음 내용을 복사하여 **신뢰 정책 편집** 양식에 붙여 넣습니다. *region-code*를 클러스터가 있는 AWS 리전으로 바꿉니다. 계정의 모든 AWS 리전에서 동일한 역할을 사용하려면 *region-code*를 `*`로 바꾸세요. *my\$1cluster*를 실제 클러스터의 이름으로 바꾸고 *111122223333*을 계정 ID로 바꿉니다. 계정의 모든 클러스터에 대해 동일한 역할을 사용하려는 경우 *my-cluster*를 `*`로 바꾸세요. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*" } }, "Principal": { "Service": "eks-fargate-pods.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. **정책 업데이트**를 선택합니다. AWS CLI 1. 다음 내용을 복사하여 `pod-execution-role-trust-policy.json`라는 파일에 붙여넣습니다. *region-code*를 클러스터가 있는 AWS 리전으로 바꿉니다. 계정의 모든 AWS 리전에서 동일한 역할을 사용하려면 *region-code*를 `*`로 바꾸세요. *my\$1cluster*를 실제 클러스터의 이름으로 바꾸고 *111122223333*을 계정 ID로 바꿉니다. 계정의 모든 클러스터에 대해 동일한 역할을 사용하려는 경우 *my-cluster*를 `*`로 바꾸세요. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*" } }, "Principal": { "Service": "eks-fargate-pods.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. 포드 실행 IAM 역할을 생성합니다. ``` aws iam create-role \ --role-name AmazonEKSFargatePodExecutionRole \ --assume-role-policy-document file://"pod-execution-role-trust-policy.json" ``` 1. 필요한 Amazon EKS 관리형 IAM 정책을 역할에 연결합니다. ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy \ --role-name AmazonEKSFargatePodExecutionRole ``` # Amazon EKS Connector IAM 역할 Kubernetes 클러스터를 연결하여 AWS Management Console에서 볼 수 있습니다. Kubernetes 클러스터에 연결하려면 IAM 역할을 생성합니다. ## 기존 EKS 커넥터 역할 확인 다음 절차를 사용하여 계정에 이미 Amazon EKS Connector 역할이 있는지 확인할 수 있습니다. 1. IAM 콘솔(https://console.aws.amazon.com/iam/)을 엽니다. 1. 왼쪽 탐색 창에서 **역할**을 선택합니다. 1. 역할 목록에서 `AmazonEKSConnectorAgentRole`(을)를 검색합니다. `AmazonEKSConnectorAgentRole`을 포함하는 역할이 존재하지 않을 경우 [Amazon EKS Connector 에이전트 역할 생성](#create-connector-role) 섹션을 참조하여 역할을 생성합니다. `AmazonEKSConnectorAgentRole`을 포함하는 역할이 존재하지 않을 경우, 연결된 정책을 볼 역할을 선택합니다. 1. **권한**을 선택합니다. 1. **AmazonEKSConnector에이전트Policy** 관리형 정책이 역할에 연결되었는지 확인합니다. 정책이 연결된 경우 Amazon EKS 커넥터 역할이 적절히 구성된 것입니다. 1. **신뢰 관계**를 선택한 후 **신뢰 정책 편집**을 선택합니다. 1. 신뢰 관계에 다음 정책이 포함되어 있는지 확인합니다. 신뢰 관계가 다음 정책과 일치하는 경우, **취소**를 선택합니다. 신뢰 관계가 일치하지 않으면 정책을 **신뢰 정책 편집** 창에 복사하고 **정책 업데이트**를 선택합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ssm.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ## Amazon EKS Connector 에이전트 역할 생성 AWS Management Console 또는 AWS CloudFormation을 사용하여 커넥터 에이전트 역할을 생성할 수 있습니다. AWS CLI 1. IAM 역할에 사용할 다음과 같은 JSON이 포함된 `eks-connector-agent-trust-policy.json`이라는 이름의 파일을 생성합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ssm.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` 1. IAM 역할에 사용할 다음과 같은 JSON이 포함된 `eks-connector-agent-policy.json`이라는 이름의 파일을 생성합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "SsmControlChannel", "Effect": "Allow", "Action": [ "ssmmessages:CreateControlChannel" ], "Resource": "arn:aws:eks:*:*:cluster/*" }, { "Sid": "ssmDataplaneOperations", "Effect": "Allow", "Action": [ "ssmmessages:CreateDataChannel", "ssmmessages:OpenDataChannel", "ssmmessages:OpenControlChannel" ], "Resource": "*" } ] } ``` 1. 이전 목록 항목에서 생성한 신뢰 정책 및 정책을 사용하여 Amazon EKS Connector 에이전트 역할을 생성합니다. ``` aws iam create-role \ --role-name AmazonEKSConnectorAgentRole \ --assume-role-policy-document file://eks-connector-agent-trust-policy.json ``` 1. Amazon EKS Connector 에이전트 역할에 정책을 연결합니다. ``` aws iam put-role-policy \ --role-name AmazonEKSConnectorAgentRole \ --policy-name AmazonEKSConnectorAgentPolicy \ --policy-document file://eks-connector-agent-policy.json ``` AWS CloudFormation 1. 다음 AWS CloudFormation 템플릿을 로컬 시스템의 텍스트 파일에 저장합니다. **참고** 이 템플릿은 또한 `registerCluster` API가 직접 호출될 때 생성되는 서비스 링크 역할도 생성합니다. 세부 정보는 [역할을 사용하여 Amazon EKS에 Kubernetes 클러스터 연결](using-service-linked-roles-eks-connector.md) 섹션을 참조하세요. ``` --- AWSTemplateFormatVersion: '2010-09-09' Description: 'Provisions necessary resources needed to register clusters in EKS' Parameters: {} Resources: EKSConnectorSLR: Type: AWS::IAM::ServiceLinkedRole Properties: AWSServiceName: eks-connector.amazonaws.com EKSConnectorAgentRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: [ 'sts:AssumeRole' ] Principal: Service: 'ssm.amazonaws.com' EKSConnectorAgentPolicy: Type: AWS::IAM::Policy Properties: PolicyName: EKSConnectorAgentPolicy Roles: - {Ref: 'EKSConnectorAgentRole'} PolicyDocument: Version: '2012-10-17' Statement: - Effect: 'Allow' Action: [ 'ssmmessages:CreateControlChannel' ] Resource: - Fn::Sub: 'arn:${AWS::Partition}:eks:*:*:cluster/*' - Effect: 'Allow' Action: [ 'ssmmessages:CreateDataChannel', 'ssmmessages:OpenDataChannel', 'ssmmessages:OpenControlChannel' ] Resource: "*" Outputs: EKSConnectorAgentRoleArn: Description: The agent role that EKS connector uses to communicate with AWS services. Value: !GetAtt EKSConnectorAgentRole.Arn ``` 1. [AWSCloudFormation 콘솔](https://console.aws.amazon.com/cloudformation/)을 엽니다. 1. 새 리소스를 사용한 **스택 생성**을 선택합니다(표준). 1. **템플릿 지정**에서 **템플릿 파일 업로드**를 선택한 다음 **파일 선택**을 선택합니다. 1. 이전에 생성한 파일을 선택한 후 **다음**을 선택합니다. 1. **스택 이름**에 `eksConnectorAgentRole`과 같은 역할 이름을 입력하고 **다음**을 선택합니다. 1. **스택 옵션 구성** 페이지에서 **다음**을 선택합니다. 1. **검토** 페이지에서 정보를 검토하고, 스택이 IAM 리소스를 생성할 수 있음을 확인한 다음 **스택 생성**을 선택합니다. # Amazon Elastic Kubernetes Service에 대한 AWS 관리형 정책 AWS 관리형 정책은 AWS에 의해 생성되고 관리되는 독립 실행형 정책입니다. AWS 관리형 정책은 사용자, 그룹 및 역할에 권한 할당을 시작할 수 있도록 많은 일반 사용 사례에 대한 권한을 제공하도록 설계되었습니다. AWS 관리형 정책은 모든 AWS 고객이 사용할 수 있기 때문에 특정 사용 사례에 대해 최소 권한을 부여하지 않을 수 있습니다. 사용 사례에 고유한 [고객 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)을 정의하여 권한을 줄이는 것이 좋습니다. AWS 관리형 정책에서 정의한 권한은 변경할 수 없습니다. AWS에서 AWS 관리형 정책에 정의된 권한을 업데이트할 경우, 정책이 연결되어 있는 모든 보안 주체 엔터티(사용자, 그룹 및 역할)에도 업데이트가 적용됩니다. 새로운 AWS 서비스를 시작하거나 새로운 API 작업을 기존 서비스에 이용하는 경우, AWS가 AWS 관리형 정책을 업데이트할 가능성이 높습니다. 자세한 내용은 *IAM 사용자 가이드*의 [AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)을 참조하세요. ## AWS 관리형 정책: AmazonEKS\$1CNI\$1Policy `AmazonEKS_CNI_Policy`를 IAM 엔터티에 연결할 수 있습니다. Amazon EC2 노드 그룹을 생성하기 전에 이 정책을 [노드 IAM 역할](create-node-role.md)에 연결하거나 Kubernetes용 Amazon VPC CNI 플러그인에 명시적으로 사용되는 IAM 역할에 연결해야 합니다. 이는 사용자를 대신하여 작업을 수행할 수 있도록 합니다. 플러그 인에서만 사용되는 역할에 정책을 연결하는 것이 좋습니다. 자세한 내용은 [Amazon VPC CNI를 통해 포드에 IP 할당](managing-vpc-cni.md) 및 [IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성](cni-iam-role.md)(을)를 참조하세요. ** 권한 세부 정보** 이 정책에는 Amazon EKS가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + ** `ec2:*NetworkInterface` 및 `ec2:*PrivateIpAddresses` ** - Amazon VPC CNI 플러그인이 Amazon EKS에서 실행되는 애플리케이션에 네트워킹을 제공하기 위해 포드의 탄력적 네트워크 인터페이스 및 IP 주소 프로비저닝과 같은 작업을 수행하도록 허용합니다. + ** `ec2` 읽기 작업** - Amazon VPC CNI 플러그인이 Amazon VPC 서브넷의 사용 가능한 IP 주소 양을 확인하기 위해 인스턴스 및 서브넷 설명과 같은 작업을 수행하도록 허용합니다. VPC CNI는 각 서브넷의 사용 가능한 IP 주소를 사용하여 탄력적 네트워크 인터페이스를 생성할 때 사용 가능한 IP 주소가 가장 많은 서브넷을 선택할 수 있습니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEKS\$1CNI\$1Policy를](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html#AmazonEKS_CNI_Policy-json) 참조하세요. ## AWS 관리형 정책: AmazonEKSClusterPolicy `AmazonEKSClusterPolicy`를 IAM 엔터티에 연결할 수 있습니다. 클러스터를 생성하기 전에 먼저 이 정책이 연결된 [클러스터 IAM 역할](cluster-iam-role.md)이 있어야 합니다. Amazon EKS에서 관리하는 Kubernetes 클러스터는 사용자 대신 다른 AWS 서비스를 직접 호출합니다. 이러한 작업을 수행하여 서비스에 사용하는 리소스를 관리합니다. 이 정책에는 Amazon EKS가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + ** `autoscaling` ** - Auto Scaling 그룹의 구성을 읽고 업데이트합니다. 이러한 권한은 Amazon EKS에서 사용되지 않지만 이전 버전과의 호환성을 위해 정책에 그대로 유지됩니다. + ** `ec2` ** - Amazon EC2 노드에 연결된 볼륨 및 네트워크 리소스로 작업합니다. 이는 Kubernetes 컨트롤 플레인이 인스턴스를 클러스터에 조인하고 Kubernetes 영구 볼륨에서 요청한 Amazon EBS 볼륨을 동적으로 프로비저닝 및 관리할 수 있도록 하기 위해 필요합니다. + ** `ec2` ** - VPC CNI에 의해 생성된 탄력적 네트워크 인터페이스를 삭제합니다. 이는 VPC CNI가 예기치 않게 종료되는 경우 EKS가 남아 있는 탄력적 네트워크 인터페이스를 정리할 수 있도록 하는 데 필요합니다. + **`elasticloadbalancing`** - 탄력적 로드 밸런서를 사용하여 노드를 대상으로 추가합니다. 이는 Kubernetes 제어 플레인이 Kubernetes 서비스에서 요청한 Elastic Load Balancer를 동적으로 프로비저닝할 수 있도록 하기 위해 필요합니다. + **`iam`** - 서비스 연결 역할을 생성합니다. 이는 Kubernetes 컨트롤 플레인이 Kubernetes 서비스에서 요청한 Elastic Load Balancer를 동적으로 프로비저닝할 수 있도록 하기 위해 필요합니다. + ** `kms` ** – AWS KMS에서 키를 읽습니다. 이는 Kubernetes 컨트롤 플레인이 `etcd`에 저장된 Kubernetes 비밀의 [비밀 암호화](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)를 지원하는 데 필요합니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEKSClusterPolicy를](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) 참조하세요. ## AWS 관리형 정책: AmazonEKSDashboardConsoleReadOnly `AmazonEKSDashboardConsoleReadOnly`를 IAM 엔티티에 연결할 수 있습니다. 이 정책에는 Amazon EKS가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + ** `eks` ** - EKS 대시보드 데이터, 리소스 및 클러스터 버전 정보에 대한 읽기 전용 액세스 권한. 이를 통해 EKS 관련 지표와 클러스터 구성 세부 정보를 볼 수 있습니다. + ** `organizations` ** - 다음을 포함한 AWS Organizations 정보에 대한 읽기 전용 액세스 권한 + 조직 세부 정보 및 서비스 액세스 보기 + 조직 루트, 계정 및 조직 단위 나열 + 조직 구조 보기 최신 버전의 JSON 정책 문서를 보려면 AWS 관리형 정책 참조 안내서의 [AmazonEKSDashboardConsoleReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardConsoleReadOnly.html#AmazonEKSDashboardConsoleReadOnly-json)를 참조하세요. ## AWS 관리형 정책: AmazonEKSFargatePodExecutionRolePolicy `AmazonEKSFargatePodExecutionRolePolicy`를 IAM 엔터티에 연결할 수 있습니다. Fargate 프로필을 생성하려면 먼저 Fargate 포드 실행 역할을 생성하고 이 정책을 이 역할에 연결해야 합니다. 자세한 내용은 [2단계: Fargate 포드 실행 역할 생성](fargate-getting-started.md#fargate-sg-pod-execution-role) 및 [시작 시 AWS Fargate를 사용하는 포드 정의](fargate-profile.md)(을)를 참조하세요. 이 정책은 Fargate에서 Amazon EKS 포드를 실행하는 데 필요한 다른 AWS 서비스 리소스에 대한 액세스를 제공하는 권한을 역할에 부여합니다. ** 권한 세부 정보** 이 정책에는 Amazon EKS가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + **`ecr`** - Fargate에서 실행 중인 포드가 Amazon ECR에 저장된 컨테이너 이미지를 가져오도록 허용합니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEKSFargatePodExecutionRolePolicy를](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html#AmazonEKSFargatePodExecutionRolePolicy-json) 참조하세요. ## AWS 관리형 정책: AmazonEKSConnectorServiceRolePolicy `AmazonEKSConnectorServiceRolePolicy`를 IAM 엔터티에 연결할 수 없습니다. 이 정책은 Amazon EKS에 사용자를 대신하여 작업을 수행할 수 있도록 서비스 연결 역할에 연결됩니다. 자세한 내용은 [역할을 사용하여 Amazon EKS에 Kubernetes 클러스터 연결](using-service-linked-roles-eks-connector.md) 섹션을 참조하세요. 이 역할을 통해 Amazon EKS는 Kubernetes 클러스터를 연결할 수 있습니다. 연결된 정책을 사용하면 역할이 등록된 Kubernetes 클러스터에 연결하는 데 필요한 리소스를 관리할 수 있습니다. ** 권한 세부 정보** 이 정책에는 Amazon EKS가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + **`SSM Management`** - SSM 활성화를 생성, 설명 및 삭제하고, 관리형 인스턴스의 등록을 취소합니다. 이를 통해 기본적인 Systems Manager 작업을 허용합니다. + **`Session Management`** - 특별히 EKS 클러스터를 위한 SSM 세션을 시작하고 AmazonEKS 문서를 사용하여 비대화형 명령을 실행합니다. + **`IAM Role Passing`** - SSM 서비스에 특별히 IAM 역할을 전달합니다. 이는 전달된 역할을 `ssm.amazonaws.com`으로 제한하는 조건에 의해 제어됩니다. + **`EventBridge Rules`** - `eks-connector.amazonaws.com`에서 관리하는 경우에만 EventBridge 규칙 및 대상을 생성합니다. 규칙은 특별히 AWS SSM(이벤트 소스에 해당함)으로 제한됩니다. 최신 버전의 JSON 정책 문서를 보려면 AWS 관리형 정책 참조 안내서의 [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html)를 참조하세요. ## AWS 관리형 정책: AmazonEKSForFargateServiceRolePolicy `AmazonEKSForFargateServiceRolePolicy`를 IAM 엔터티에 연결할 수 없습니다. 이 정책은 Amazon EKS에 사용자를 대신하여 작업을 수행할 수 있도록 서비스 연결 역할에 연결됩니다. 자세한 내용은 `AWSServiceRoleforAmazonEKSForFargate` 섹션을 참조하세요. 이 정책은 Amazon EKS에 Fargate 태스크를 실행하는 데 필요한 권한을 부여합니다. 이 정책은 Fargate 노드가 있는 경우에만 사용됩니다. ** 권한 세부 정보** 이 정책에는 Amazon EKS가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + **`ec2`** – 탄력적 네트워크 인터페이스를 생성 및 삭제하고, 탄력적 네트워크 인터페이스 및 리소스를 설명합니다. 이는 Amazon EKS Fargate 서비스가 Fargate 포드에 필요한 VPC 네트워킹을 구성할 수 있도록 하기 위해 필요합니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEKSForFargateServiceRolePolicy를](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html#AmazonEKSForFargateServiceRolePolicy-json) 참조하세요. ## AWS 관리형 정책: AmazonEKSComputePolicy `AmazonEKSComputePolicy`를 IAM 엔티티에 연결할 수 있습니다. 이 정책을 [클러스터 IAM 역할](cluster-iam-role.md)에 연결하여 EKS가 계정에서 관리할 수 있는 리소스를 확장할 수 있습니다. 이 정책은 Amazon EKS가 EKS 클러스터에 대한 EC2 인스턴스 생성 및 관리에 필요한 권한과 EC2 구성에 필요한 IAM 권한을 부여합니다. 또한 이 정책은 Amazon EKS가 사용자를 대신하여 EC2 Spot 서비스 연결 역할을 생성할 수 있는 권한을 부여합니다. ### 권한 세부 정보 이 정책에는 Amazon EKS가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + ** `ec2` 권한**: + `ec2:CreateFleet` 및 `ec2:RunInstances`-EC2 인스턴스를 생성하고 EKS 클러스터 노드에 대한 특정 EC2 리소스(이미지, 보안 그룹, 서브넷)를 사용할 수 있습니다. + `ec2:CreateLaunchTemplate`-EKS 클러스터 노드에 대한 EC2 시작 템플릿을 생성할 수 있습니다. + 이 정책에는 이러한 EC2 권한 사용을 EKS 클러스터 이름 및 기타 관련 태그가 지정된 리소스로 제한하는 조건도 포함되어 있습니다. + `ec2:CreateTags`-`CreateFleet`, `RunInstances`, `CreateLaunchTemplate` 작업에서 생성한 EC2 리소스에 태그를 추가할 수 있습니다. + ** `iam` 권한**: + `iam:AddRoleToInstanceProfile`-EKS 컴퓨팅 인스턴스 프로파일에 IAM 역할을 추가할 수 있습니다. + `iam:PassRole`-필요한 IAM 역할을 EC2 서비스에 전달할 수 있습니다. 최신 버전의 JSON 정책 문서를 보려면 AWS 관리형 정책 참조 안내서의 [AmazonEKSComputePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSComputePolicy.html#AmazonEKSComputePolicy-json)를 참조하세요. ## AWS 관리형 정책: AmazonEKSNetworkingPolicy `AmazonEKSNetworkingPolicy`를 IAM 엔티티에 연결할 수 있습니다. 이 정책을 [클러스터 IAM 역할](cluster-iam-role.md)에 연결하여 EKS가 계정에서 관리할 수 있는 리소스를 확장할 수 있습니다. 이 정책은 Amazon EKS가 EKS 클러스터에 대한 네트워크 인터페이스를 생성하고 관리하는 데 필요한 권한을 부여하여 제어 영역과 작업자 노드가 통신하고 제대로 작동할 수 있도록 설계되었습니다. ### 권한 세부 정보 이 정책은 Amazon EKS가 클러스터의 네트워크 인터페이스를 관리할 수 있도록 허용하는 다음과 같은 권한을 부여합니다. + ** `ec2` 네트워크 인터페이스 권한 ID** + `ec2:CreateNetworkInterface`-EC2 네트워크 인터페이스를 생성할 수 있습니다. + 이 정책에는 EKS 클러스터 이름 및 Kubernetes CNI 노드 이름으로 태그가 지정된 네트워크 인터페이스에 대한 이 권한 사용을 제한하는 조건이 포함되어 있습니다. + `ec2:CreateTags`-`CreateNetworkInterface` 작업에서 생성한 네트워크 인터페이스에 태그를 추가할 수 있습니다. + ** `ec2` 네트워크 인터페이스 관리 권한**: + `ec2:AttachNetworkInterface`, `ec2:ModifyNetworkInterfaceAttribute`, `ec2:DetachNetworkInterface` - 네트워크 인터페이스 속성을 연결 및 수정하고 EC2 인스턴스에 대한 네트워크 인터페이스를 분리할 수 있습니다. + `ec2:UnassignPrivateIpAddresses`, `ec2:UnassignIpv6Addresses`, `ec2:AssignPrivateIpAddresses`, `ec2:AssignIpv6Addresses`-네트워크 인터페이스의 IP 주소 할당을 관리할 수 있습니다. + 이러한 권한은 EKS 클러스터 이름으로 태그가 지정된 네트워크 인터페이스로 제한됩니다. 최신 버전의 JSON 정책 문서를 보려면 AWS 관리형 정책 참조 안내서의 [AmazonEKSNetworkingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSNetworkingPolicy.html#AmazonEKSNetworkingPolicy-json)를 참조하세요. ## AWS 관리형 정책: AmazonEKSBlockStoragePolicy `AmazonEKSBlockStoragePolicy`를 IAM 엔티티에 연결할 수 있습니다. 이 정책을 [클러스터 IAM 역할](cluster-iam-role.md)에 연결하여 EKS가 계정에서 관리할 수 있는 리소스를 확장할 수 있습니다. 이 정책은 Amazon EKS가 EKS 클러스터에 대한 EC2 볼륨 및 스냅샷을 생성, 관리 및 유지하는 데 필요한 권한을 부여하여 컨트롤 플레인과 워커 노드가 Kubernetes 워크로드에서 요구하는 영구 스토리지를 프로비저닝하고 사용할 수 있게 합니다. ### 권한 세부 정보 이 IAM 정책은 Amazon EKS가 EC2 볼륨 및 스냅샷을 관리할 수 있도록 다음과 같은 권한을 부여합니다. + ** `ec2` 볼륨 관리 권한**: + `ec2:AttachVolume`, `ec2:DetachVolume`, `ec2:ModifyVolume`, `ec2:EnableFastSnapshotRestores`-EC2 볼륨에 대한 빠른 스냅샷 복원을 연결, 분리, 수정, 활성화할 수 있습니다. + 이러한 권한은 EKS 클러스터 이름으로 태그가 지정된 볼륨으로 제한됩니다. + `ec2:CreateTags`-`CreateVolume` 및 `CreateSnapshot` 작업에서 생성된 EC2 볼륨 및 스냅샷에 태그를 추가할 수 있습니다. + ** `ec2` 볼륨 생성 권한**: + `ec2:CreateVolume`-새 EC2 볼륨을 생성할 수 있습니다. + 이 정책에는 이 권한의 사용을 EKS 클러스터 이름 및 기타 관련 태그가 지정된 볼륨으로 제한하는 조건이 포함되어 있습니다. + `ec2:CreateSnapshot`-새 EC2 볼륨 스냅샷을 생성할 수 있습니다. + 이 정책에는 이 권한의 사용을 EKS 클러스터 이름 및 기타 관련 태그가 지정된 스냅샷으로 제한하는 조건이 포함되어 있습니다. 최신 버전의 JSON 정책 문서를 보려면 AWS 관리형 정책 참조 안내서의 [AmazonEKSBlockStoragePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSBlockStoragePolicy.html#AmazonEKSBlockStoragePolicy-json)를 참조하세요. ## AWS 관리형 정책: AmazonEKSLoadBalancingPolicy `AmazonEKSLoadBalancingPolicy`를 IAM 엔티티에 연결할 수 있습니다. 이 정책을 [클러스터 IAM 역할](cluster-iam-role.md)에 연결하여 EKS가 계정에서 관리할 수 있는 리소스를 확장할 수 있습니다. 이 IAM 정책은 Amazon EKS가 다양한 AWS 서비스를 함께 사용하여 Elastic Load Balancing(ELB) 및 관련 리소스를 관리하는 데 필요한 권한을 부여합니다. ### 권한 세부 정보 이 정책에서 부여하는 주요 권한은 다음과 같습니다. + **`elasticloadbalancing`**: 탄력적 로드 밸런서 및 대상 그룹을 생성, 수정, 관리할 수 있습니다. 여기에는 로드 밸런서, 대상 그룹, 리스너, 규칙을 생성, 업데이트, 삭제하는 권한이 포함됩니다. + **`ec2`**: Kubernetes 컨트롤 플레인이 인스턴스를 클러스터에 조인하고 Amazon EBS 볼륨을 관리하는 데 필요한 보안 그룹을 생성하고 관리할 수 있습니다. 또한 인스턴스, VPC, 서브넷, 보안 그룹 및 기타 네트워킹 리소스와 같은 EC2 리소스를 설명하고 나열할 수 있습니다. + **`iam`**: Kubernetes 컨트롤 플레인이 ELB를 동적으로 프로비저닝하는 데 필요한 탄력적 로드 밸런싱에 대한 서비스 연결 역할을 생성할 수 있습니다. + ** `kms` **: AWS KMS에서 키를 읽을 수 있습니다. 이 키는 Kubernetes 컨트롤 플레인이 etcd에 저장된 Kubernetes 보안 암호의 암호화를 지원하기 위해 필요합니다. + ** `wafv2` ** 및 ** `shield` **: 웹 ACL을 연결 및 연결 해제하고 Elastic Load Balancer에 대한 AWS Shield 보호를 생성/삭제할 수 있습니다. + ** `cognito-idp` **, ** `acm` **, ** `elasticloadbalancing` **: 사용자 풀 클라이언트를 설명하고, 인증서를 나열 및 설명하고, Kubernetes 컨트롤 플레인이 Elastic Load Balancer를 관리하는 데 필요한 대상 그룹을 설명할 수 있는 권한을 부여합니다. 또한 이 정책에는 `eks:eks-cluster-name` 태그를 사용하여 관리 중인 특정 EKS 클러스터에 대한 권한 범위를 확인하기 위한 여러 조건 확인이 포함되어 있습니다. 최신 버전의 JSON 정책 문서를 보려면 AWS 관리형 정책 참조 안내서의 [AmazonEKSLoadBalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html#AmazonEKSLoadBalancingPolicy-json)를 참조하세요. ## AWS 관리형 정책: AmazonEKSMCPReadOnlyAccess `AmazonEKSMCPReadOnlyAccess`를 IAM 엔티티에 연결할 수 있습니다. 이 정책은 Amazon EKS 리소스 및 관련 AWS 서비스에 대한 읽기 전용 액세스를 제공하므로, 이를 통해 Amazon EKS Model Context Protocol(MCP) 서버가 인프라를 수정하지 않고도 관찰성 및 문제 해결 작업을 수행할 수 있습니다. ** 권한 세부 정보** 이 정책에는 위탁자가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + **`eks`**: 위탁자가 EKS 클러스터, 노드 그룹, 추가 기능, 액세스 항목, 인사이트를 설명 및 나열하고, 읽기 전용 작업을 위해 Kubernetes API에 액세스하도록 허용합니다. + **`iam`**: 위탁자가 IAM 역할, 정책 및 연결에 대한 정보를 검색하여 EKS 리소스와 관련된 권한을 이해하도록 허용합니다. + **`ec2`**: 위탁자가 VPC, 서브넷 및 라우팅 테이블을 설명하여 EKS 클러스터의 네트워크 구성을 이해하도록 허용합니다. + **`sts`**: 위탁자가 인증 및 권한 부여 목적으로 발신자 ID 정보를 검색하도록 허용합니다. + **`logs`**: 위탁자가 문제 해결 및 모니터링을 위해 CloudWatch Logs에서 쿼리를 시작하고 쿼리 결과를 검색하도록 허용합니다. + **`cloudwatch`**: 위탁자가 클러스터 및 워크로드 성능 모니터링을 위해 지표 데이터를 검색하도록 허용합니다. + **`eks-mcp`**: 위탁자가 Amazon EKS MCP 서버 내에서 MCP 작업을 간접 호출하고 읽기 전용 도구를 직접 호출하도록 허용합니다. 최신 버전의 JSON 정책 문서를 보려면 AWS 관리형 정책 참조 안내서의 [AmazonEKSMCPReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSMCPReadOnlyAccess.html)를 참조하세요. ## AWS 관리형 정책: AmazonEKSServicePolicy `AmazonEKSServicePolicy`를 IAM 엔티티에 연결할 수 있습니다. 2020년 4월 16일 이전에 생성된 클러스터에서는 IAM 역할을 만들어 이 정책을 역할에 연결해야 했습니다. 2020년 4월 16일 이후에 생성된 클러스터에서는 역할을 생성할 필요가 없으며 이 정책을 할당할 필요가 없습니다. `iam:CreateServiceLinkedRole` 권한이 있는 IAM 보안 주체를 사용하여 클러스터를 생성하는 경우 [ AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) 서비스 연결 역할이 자동으로 생성됩니다. 서비스 연결 역할에는 [관리형 정책: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)가 연결되어 있습니다. 이 정책을 통해 Amazon EKS는 Amazon EKS 클러스터를 운영하는 데 필요한 리소스를 생성하고 관리할 수 있습니다. ** 권한 세부 정보** 이 정책에는 Amazon EKS가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + **`eks`** - 사용자가 업데이트를 시작한 후 클러스터의 Kubernetes 버전을 업데이트합니다. 이 권한은 Amazon EKS에 사용되지 않지만 이전 버전과의 호환성을 위해 정책에 그대로 유지됩니다. + **`ec2`** - 탄력적 네트워크 인터페이스 및 기타 네트워크 리소스와 태그를 사용합니다. 이는 Amazon EKS에서 노드와 Kubernetes 제어부 간의 통신을 용이하게 하는 네트워킹을 구성하는 데 필요합니다. 보안 그룹에 대한 정보를 읽습니다. 보안 그룹의 태그를 업데이트합니다. + **`route53`** - VPC를 호스팅 영역에 연결합니다. 이는 Amazon EKS에서 Kubernetes 클러스터 API 서버에 프라이빗 엔드포인트 네트워킹을 활성화하는 데 필요합니다. + **`logs`** - 로그 이벤트. 이는 Amazon EKS가 Kubernetes 제어 영역 로그를 CloudWatch로 전송하기 위해 필요합니다. + **`iam`** - 서비스 연결 역할을 생성합니다. 이는 Amazon EKS가 사용자를 대신하여 [Amazon EKS에 대한 서비스 연결 역할 권한](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) 서비스 연결 역할을 생성하는 데 필요합니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEKSServicePolicy를](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html#AmazonEKSServicePolicy-json) 참조하세요. ## AWS 관리형 정책: AmazonEKSServiceRolePolicy `AmazonEKSServiceRolePolicy`를 IAM 엔터티에 연결할 수 없습니다. 이 정책은 Amazon EKS에 사용자를 대신하여 작업을 수행할 수 있도록 서비스 연결 역할에 연결됩니다. 자세한 내용은 [Amazon EKS에 대한 서비스 연결 역할 권한](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) 섹션을 참조하세요. `iam:CreateServiceLinkedRole` 권한이 있는 IAM 보안 주체를 사용하여 클러스터를 생성하는 경우 [ AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) 서비스 연결 역할이 자동으로 생성되며 이 정책이 연결됩니다. 이 정책을 사용하면 서비스 연결 역할이 사용자를 대신하여 AWS 서비스를 직접 호출할 수 있습니다. ** 권한 세부 정보** 이 정책에는 Amazon EKS가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + **`ec2`** - 탄력적 네트워크 인터페이스와 Amazon EC2 인스턴스, 클러스터 보안 그룹 및 클러스터를 생성하는 데 필요한 VPC를 생성하고 설명합니다. 자세한 내용은 [클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기](sec-group-reqs.md) 섹션을 참조하세요. 보안 그룹에 대한 정보를 읽습니다. 보안 그룹의 태그를 업데이트합니다. 온디맨드 용량 예약에 대한 자세한 내용을 읽으세요. 라우팅 테이블 및 네트워크 ACL을 포함한 VPC 구성을 읽어 클러스터 인사이트의 일부로 구성 문제를 감지합니다. + ** `ec2` Auto Mode** - EKS Auto Mode에서 생성된 EC2 인스턴스를 종료합니다. 자세한 내용은 [EKS Auto Mode를 사용하여 클러스터 인프라 자동화](automode.md) 섹션을 참조하세요. + **`iam`** - IAM 역할에 연결된 모든 관리형 정책을 나열합니다. 이는 Amazon EKS가 클러스터 생성에 필요한 모든 관리형 정책 및 권한을 나열하고 검증하는 데 필요합니다. + **호스팅 영역과 VPC 연결** - 이는 Amazon EKS에서 Kubernetes 클러스터 API 서버에 프라이빗 엔드포인트 네트워킹을 사용 설정하는 데 필요합니다. + **로그 이벤트** - 이는 Amazon EKS가 Kubernetes 제어 영역 로그를 CloudWatch로 전송하기 위해 필요합니다. + **지표 입력** - Amazon EKS가 Kubernetes 컨트롤 플레인 로그를 CloudWatch로 전송하기 위해 필요합니다. + **`eks`** - 클러스터 액세스 항목 및 정책을 관리하여 EKS 리소스에 액세스할 수 있는 사용자와 수행 가능한 작업을 세밀하게 제어할 수 있습니다. 여기에는 컴퓨팅, 네트워킹, 로드 밸런싱, 스토리지 작업에 대한 표준 액세스 정책 연결이 포함됩니다. + **`elasticloadbalancing`** - EKS 클러스터와 연결된 로드 밸런서 및 해당 구성 요소(리스너, 대상 그룹, 인증서)를 생성, 관리, 삭제합니다. 로드 밸런서 속성 및 상태를 봅니다. + ** `events` **-EKS 클러스터와 관련된 EC2 및 AWS 상태 이벤트를 모니터링하기 위한 EventBridge 규칙을 생성하고 관리하여 인프라 변경 및 상태 알림에 대한 자동 응답을 활성화합니다. + **`iam`** - EKS 노드 관리에 필요한 생성, 삭제, 역할 연결을 포함하여 'eks' 접두사가 있는 EC2 인스턴스 프로파일을 관리합니다. 사용자가 사용할 워커 노드에 대한 사용자 지정 인스턴스 프로파일을 정의할 수 있도록 인스턴스 프로파일을 설명할 수 있습니다. + **`pricing`** 및 **`shield`** - AWS 요금 정보 및 Shield 보호 상태에 액세스하고 이를 통해 EKS 리소스에 대한 비용 관리 및 고급 보안 기능을 활성화합니다. + **리소스 정리**-클러스터 정리 작업 중에 볼륨, 스냅샷, 시작 템플릿, 네트워크 인터페이스를 포함하여 EKS 태그가 지정된 리소스를 안전하게 삭제합니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEKSServiceRolePolicy를](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html#AmazonEKSServiceRolePolicy-json) 참조하세요. ## AWS 관리형 정책: AmazonEKSVPCResourceController `AmazonEKSVPCResourceController` 정책을 IAM ID에 연결할 수 있습니다. [포드에 보안 그룹](security-groups-for-pods.md)을 사용하는 경우, 사용자를 대신하여 작업을 수행하려면 이 정책을 [Amazon EKS 클러스터 IAM 역할](cluster-iam-role.md)에 첨부해야 합니다. 이 정책은 노드의 탄력적 네트워크 인터페이스 및 IP 주소를 관리하기 위한 클러스터 역할에 권한을 부여합니다. ** 권한 세부 정보** 이 정책에는 Amazon EKS가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + **`ec2`** - 탄력적 네트워크 인터페이스 및 IP 주소를 관리하여 포드 보안 그룹 및 Windows 노드를 지원합니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEKSVPCResourceController를](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html#AmazonEKSVPCResourceController-json) 참조하세요. ## AWS 관리형 정책: AmazonEKSWorkerNodePolicy `AmazonEKSWorkerNodePolicy`를 IAM 엔터티에 연결할 수 있습니다. 이 정책을 Amazon EC2 노드 생성 시에 지정한, Amazon EKS에서 사용자를 대신하여 작업을 수행하도록 허용하는 [IAM 역할](create-node-role.md)에 연결해야 합니다. `eksctl`을 사용하여 노드 그룹을 생성하는 경우, 노드 IAM 역할을 생성하고 이 정책을 역할에 자동으로 연결합니다. 이 정책은 Amazon EKS Amazon EC2 노드에 Amazon EKS 클러스터에 연결할 수 있는 권한을 부여합니다. ** 권한 세부 정보** 이 정책에는 Amazon EKS가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + **`ec2`** - 인스턴스 볼륨 및 네트워크 정보를 읽습니다. 이는 Kubernetes 노드가 Amazon EKS 클러스터에 가입하는 데 필요한 Amazon EC2 리소스에 대한 정보를 설명하는 데 필요합니다. + **`eks`** - 선택적으로 클러스터를 노드 부트스트래핑의 일부로 설명합니다. + **`eks-auth:AssumeRoleForPodIdentity`** - 노드에서 EKS 워크로드에 대한 자격 증명 검색을 허용합니다. EKS Pod Identity가 제대로 작동하려면 필요합니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEKSWorkerNodePolicy를](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html#AmazonEKSWorkerNodePolicy-json) 참조하세요. ## AWS 관리형 정책: AmazonEKSWorkerNodeMinimalPolicy AmazonEKSWorkerNodeMinimalPolicy를 IAM 엔티티에 연결할 수 있습니다. 이 정책을 Amazon EC2 노드 생성 시에 지정한, Amazon EKS에서 사용자를 대신하여 작업을 수행하도록 허용하는 IAM 역할에 연결할 수 있습니다. 이 정책은 Amazon EKS Amazon EC2 노드에 Amazon EKS 클러스터에 연결할 수 있는 권한을 부여합니다. 이 정책은 AmazonEKSWorkerNodePolicy에 비해 권한이 적습니다. ** 권한 세부 정보** 이 정책에는 Amazon EKS가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + `eks-auth:AssumeRoleForPodIdentity` - 노드에서 EKS 워크로드에 대한 보안 인증 정보 검색을 허용합니다. EKS Pod Identity가 제대로 작동하려면 필요합니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEKSWorkerNodePolicy를](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodeMinimalPolicy.html#AmazonEKSWorkerNodeMinimalPolicy-json) 참조하세요. ## AWS 관리형 정책: AWSServiceRoleForAmazonEKSNodegroup `AWSServiceRoleForAmazonEKSNodegroup`를 IAM 엔터티에 연결할 수 없습니다. 이 정책은 Amazon EKS에 사용자를 대신하여 작업을 수행할 수 있도록 서비스 연결 역할에 연결됩니다. 자세한 내용은 [Amazon EKS에 대한 서비스 연결 역할 권한](using-service-linked-roles-eks-nodegroups.md#service-linked-role-permissions-eks-nodegroups) 섹션을 참조하세요. 이 정책은 계정에서 Amazon EC2 노드 그룹을 생성하고 관리하도록 허용하는 `AWSServiceRoleForAmazonEKSNodegroup` 역할 권한을 부여합니다. ** 권한 세부 정보** 이 정책에는 Amazon EKS가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다. + **`ec2`** - 보안 그룹, 태그, 용량 예약, 시작 템플릿을 사용합니다. 이는 Amazon EKS 관리형 노드 그룹이 원격 액세스 구성을 활성화하고 관리형 노드 그룹에서 사용할 수 있는 용량 예약을 설명하는 데 필요합니다. 또한 Amazon EKS 관리 노드 그룹은 사용자를 대신하여 시작 템플릿을 생성합니다. 이는 각 관리형 노드 그룹을 백업하는 Amazon EC2 Auto Scaling 그룹을 구성하기 위한 것입니다. + **`iam`** - 서비스 연결 역할을 생성하고 역할을 전달합니다. 이는 Amazon EKS 관리형 노드 그룹이 관리형 노드 그룹을 생성할 때 전달되는 역할의 인스턴스 프로필을 관리하는 데 필요합니다. 이 인스턴스 프로필은 관리형 노드 그룹의 일부로 시작된 Amazon EC2 인스턴스에 사용됩니다. Amazon EKS는 Amazon EC2 Auto Scaling 그룹과 같은 다른 서비스에 대한 서비스 연결 역할을 생성해야 합니다. 이러한 권한은 관리 노드 그룹 생성에 사용됩니다. + **`autoscaling`** - 보안 Auto Scaling 그룹을 사용합니다. 이는 Amazon EKS 관리 노드 그룹이 각 관리 노드 그룹을 백업하는 Amazon EC2 Auto Scaling 그룹을 관리하는 데 필요합니다. 또한 노드 그룹을 업데이트하고 관리형 노드 그룹에서 구성된 웜 풀을 관리하는 중에 노드가 종료되거나 재활용될 때 포드 제거와 같은 기능을 지원하는 데에도 사용됩니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AWSServiceRoleForAmazonEKSNodegroup를](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html#AWSServiceRoleForAmazonEKSNodegroup-json) 참조하세요. ## AWS 관리형 정책: AmazonEKSDashboardServiceRolePolicy `AmazonEKSDashboardServiceRolePolicy`를 IAM 엔터티에 연결할 수 없습니다. 이 정책은 Amazon EKS에 사용자를 대신하여 작업을 수행할 수 있도록 서비스 연결 역할에 연결됩니다. 자세한 내용은 [Amazon EKS에 대한 서비스 연결 역할 권한](using-service-linked-roles-eks-dashboard.md#service-linked-role-permissions-eks-dashboard) 섹션을 참조하세요. 이 정책은 계정에서 Amazon EC2 노드 그룹을 생성하고 관리하도록 허용하는 `AWSServiceRoleForAmazonEKSDashboard` 역할 권한을 부여합니다. ** 권한 세부 정보** 이 정책에는 이러한 태스크를 완료하기 위해 액세스를 허용하는 다음 권한이 포함되어 있습니다. + ** `organizations` ** - AWS Organizations 구조 및 계정에 대한 정보를 봅니다. 여기에는 조직의 계정을 나열하고, 조직 단위 및 루트를 보고, 위임 관리자를 나열하고, 조직에 액세스할 수 있는 서비스를 보고, 조직 및 계정에 대한 세부 정보를 검색할 수 있는 권한이 포함됩니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json)를 참조하세요. ## AWS 관리형 정책: AmazonEBSCSIDriverPolicy `AmazonEBSCSIDriverPolicy` 정책은 Amazon EBS Container Storage Interface(CSI) 드라이버가 사용자를 대신하여 볼륨을 생성, 수정, 복사, 연결, 분리 및 삭제하도록 허용합니다. 여기에는 기존 볼륨에서 태그를 수정하고 EBS 볼륨에서 빠른 스냅샷 복원(FSR)을 활성화하는 작업이 포함됩니다. 또한 EBS CSI 드라이버에 스냅샷을 생성, 잠금, 복원 및 삭제하고 인스턴스, 볼륨 및 스냅샷을 나열할 권한을 부여합니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEBSCSIDriverServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html#AmazonEBSCSIDriverPolicy-json)를 참조하세요. ## AWS 관리형 정책: AmazonEFSCSIDriverPolicy `AmazonEFSCSIDriverPolicy` 정책을 통해 Amazon EFS 컨테이너 스토리지 인터페이스(CSI)가 사용자를 대신하여 액세스 포인트를 생성하고 삭제할 수 있습니다. 또한 Amazon EFS CSI 드라이버에 액세스 포인트, 파일 시스템, 탑재 대상 및 Amazon EC2 가용 영역을 나열할 수 있는 권한을 부여합니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEFSCSIDriverServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEFSCSIDriverPolicy.html#AmazonEFSCSIDriverPolicy-json)를 참조하세요. ## AWS 관리형 정책: AmazonEKSLocalOutpostClusterPolicy IAM 엔터티에 이 정책을 연결할 수 있습니다. 로컬 클러스터를 생성하기 전에 이 정책을 [클러스터 역할](cluster-iam-role.md)에 연결해야 합니다. Amazon EKS에서 관리하는 Kubernetes 클러스터는 사용자 대신 다른 AWS 서비스를 직접 호출합니다. 이러한 작업을 수행하여 서비스에 사용하는 리소스를 관리합니다. `AmazonEKSLocalOutpostClusterPolicy`에는 다음 권한이 포함되어 있습니다. + **`ec2` 읽기 작업**-컨트롤 플레인 인스턴스가 가용 영역, 라우팅 테이블, 인스턴스, 네트워크 인터페이스 속성을 설명하도록 허용합니다. Amazon EC2 인스턴스가 성공적으로 클러스터에 컨트롤 플레인 인스턴스로 조인하는 데 필요한 권한입니다. + **`ssm`** – Amazon EKS가 계정의 로컬 클러스터와 통신하고 이를 관리하는 데 사용하는 컨트롤 플레인 인스턴스에 대한 Amazon EC2 Systems Manager 연결을 허용합니다. + **`logs`** - 인스턴스가 Amazon CloudWatch에 로그를 푸시하도록 허용합니다. + ** `secretsmanager` ** - 인스턴스가 AWS Secrets Manage 에서 안전하게 컨트롤 플레인 인스턴스에 대한 부트스트랩 데이터를 가져오고 삭제하도록 허용합니다. + **`ecr`** – 컨트롤 플레인 인스턴스에서 실행 중인 포드 및 컨테이너가 Amazon Elastic Container Registry에 저장된 컨테이너 이미지를 끌어오도록 허용합니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEKS\$1CNI\$1Policy를](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html#AmazonEKSLocalOutpostClusterPolicy-json) 참조하세요. ## AWS 관리형 정책: AmazonEKSLocalOutpostServiceRolePolicy IAM 엔터티에 이 정책을 연결할 수 없습니다. `iam:CreateServiceLinkedRole` 권한이 있는 IAM 보안 주체를 사용하여 클러스터를 생성하면 Amazon EKS가 자동으로 [AWSServiceRoleforAmazonEKSLocalOutpost](using-service-linked-roles-eks-outpost.md) 서비스 연결 역할을 생성하고 이 정책을 연결합니다. 이 정책을 사용하면 서비스 연결 역할이 로컬 클러스터에 대해 사용자를 대신하여 AWS 서비스를 직접 호출할 수 있습니다. `AmazonEKSLocalOutpostServiceRolePolicy`에는 다음 권한이 포함되어 있습니다. + **`ec2`** - Amazon EKS가 보안, 네트워크 및 기타 리소스와 함께 작동하여 계정에서 컨트롤 플레인 인스턴스를 성공적으로 시작하고 관리하도록 허용합니다. + **`ssm`, `ssmmessages`** - Amazon EKS가 계정의 로컬 클러스터와 통신하고 이를 관리하는 데 사용하는 컨트롤 플레인 인스턴스에 대한 Amazon EC2 Systems Manager 연결을 허용합니다. + **`iam`** - Amazon EKS가 컨트롤 플레인 인스턴스와 연결된 인스턴스 프로파일을 관리하도록 허용합니다. + ** `secretsmanager` ** - 인스턴스 부트스트랩 중 안전하게 참조할 수 있게 Amazon EKS가 컨트롤 플레인 인스턴스에 대한 부트스트랩 데이터를 AWS Secrets Manager에 저장하도록 허용합니다. + **`outposts`** - Amazon EKS가 계정에서 Outpost 정보를 가져와 Outpost에서 로컬 클러스터를 성공적으로 시작하도록 허용합니다. 최신 버전의 JSON 정책 문서를 보려면AWS 관리형 정책 참조 안내서의 [AmazonEKS\$1CNI\$1Policy를](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostServiceRolePolicy.html#AmazonEKSLocalOutpostServiceRolePolicy-json) 참조하세요. ## AWS 관리형 정책에 대한 Amazon EKS 업데이트 이 서비스에서 이러한 변경 사항 추적을 시작한 이후 Amazon EKS에 대한 AWS 관리형 정책 업데이트에 대한 세부 정보를 확인합니다. 이 특정 설명서 페이지의 모든 소스 파일 변경 사항에 대한 알림을 받으려면 RSS 리더를 사용하여 다음 URL을 구독하세요. ``` https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/security/iam-reference/security-iam-awsmanpol.adoc.atom ``` | 변경 | 설명 | 날짜 | | --- | --- | --- | | [AWS 관리형 정책: AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)에 권한이 추가되었습니다. | `AmazonEKSNetworkingPolicy`에서 `ec2:ModifyNetworkInterfaceAttribute` 권한을 추가했습니다. 이를 통해 Amazon EKS Auto Mode 컨트롤러에서 EC2 인스턴스와 관련된 네트워크 인터페이스 속성을 수정할 수 있습니다. | 2026년 2월 3일 | | [AWS 관리형 정책: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)에 권한이 추가되었습니다. | `AWSServiceRoleForAmazonEKSNodegroup`에 `autoscaling:PutWarmPool`, `autoscaling:DeleteWarmPool` 및 `autoscaling:DescribeWarmPool` 권한을 추가했습니다. 이를 통해 Amazon EKS 관리형 노드 그룹에서 노드 그룹 수명 주기 전반에 걸쳐 기본 ASG 웜 풀 리소스를 관리할 수 있습니다. | 2026년 2월 17일 | | [AWS 관리형 정책: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)에 권한이 추가되었습니다. | `AmazonEKSServiceRolePolicy`의 `iam:GetInstanceProfile` 권한에 대한 대상 인스턴스 프로파일 이름에서 'eks' 접두사 요구 사항을 제거했습니다. 이를 통해 Amazon EKS Auto Mode는 'eks' 이름 지정 접두사 없이 NodeClasses에서 사용자 지정 인스턴스 프로파일을 검증하고 활용할 수 있습니다. | 2026년 2월 2일 | | [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy)에 권한을 추가했습니다. | EBS CSI 드라이버가 EBS 스냅샷을 직접 잠글 수 있도록 `ec2:LockSnapshot` 권한을 추가했습니다. | 2026년 1월 15일 | | [AWS 관리형 정책: AmazonEKSMCPReadOnlyAccess](#security-iam-awsmanpol-amazoneksmcpreadonlyaccess)를 소개합니다. | Amazon EKS는 관찰성 및 문제 해결을 위해 Amazon EKS MCP 서버에서 읽기 전용 도구를 활성화하도록 새로운 관리형 정책 `AmazonEKSMCPReadOnlyAccess`를 도입했습니다. | 2025년 11월 21일 | | [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy)에 권한을 추가했습니다. | EBS CSI 드라이버가 EBS 볼륨을 직접 복사할 수 있도록 `ec2:CopyVolumes` 권한을 추가했습니다. | 2025년 11월 17일 | | [AWS 관리형 정책: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)에 권한이 추가되었습니다. | `AmazonEKSServiceRolePolicy`에 `ec2:DescribeRouteTables` 및 `ec2:DescribeNetworkAcls` 권한을 추가했습니다. 이를 통해 Amazon EKS는 클러스터 인사이트의 일부로 하이브리드 노드에 대한 VPC 라우팅 테이블 및 네트워크 ACL의 구성 문제를 감지할 수 있습니다. | 2025년 10월 22일 | | [AWSServiceRoleForAmazonEKSConnector](using-service-linked-roles-eks-connector.md)에 권한을 추가함 | `ssmmessages:OpenDataChannel`에 `AmazonEKSConnectorServiceRolePolicy` 권한을 추가함 | 2025년 10월 15일 | | [AWS 관리형 정책: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)에 권한 추가됨 | 이 역할은 새 액세스 정책 `AmazonEKSEventPolicy`를 연결할 수 있습니다. `ec2:DeleteLaunchTemplate` 및 `ec2:TerminateInstances`에 대한 권한이 제한됩니다. | 2025년 8월 26일 | | [AWS 관리형 정책: AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy)에 권한 추가됨 | `AmazonEKSLocalOutpostServiceRolePolicy`에 `ssmmessages:OpenDataChannel` 권한이 추가되었습니다. | 2025년 6월 26일 | | [AWS 관리형 정책: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy)에 권한이 추가되었습니다. | 용량 예약 ` arn:aws:ec2:*:*:capacity-reservation/*`을 포함하도록 `ec2:RunInstances` 및 `ec2:CreateFleet` 작업에 대한 리소스 권한이 업데이트되었습니다. 이를 통해 Amazon EKS 자동 모드에서 계정의 EC2 온디맨드 용량 예약을 사용하여 인스턴스를 시작할 수 있습니다. Amazon EKS 자동 모드에서 사용자를 대신하여 EC2 Spot 서비스 연결 역할 `AWSServiceRoleForEC2Spot`을 생성할 수 있도록 `iam:CreateServiceLinkedRole`이 추가되었습니다. | 2025년 6월 20일 | | [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)에 권한이 추가되었습니다. | Amazon EKS 자동 모드에서 계정의 EC2 온디맨드 용량 예약을 사용하여 인스턴스를 시작할 수 있도록 `ec2:DescribeCapacityReservations` 권한이 추가되었습니다. | 2025년 6월 20일 | | [AWS 관리형 정책: AmazonEKSDashboardConsoleReadOnly](#security-iam-awsmanpol-amazoneksdashboardconsolereadonly)를 소개합니다. | 새 `AmazonEKSDashboardConsoleReadOnly` 정책이 도입되었습니다. | 2025년 6월 19일 | | [AWS 관리형 정책: AmazonEKSDashboardServiceRolePolicy](#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy)를 소개합니다. | 새 `AmazonEKSDashboardServiceRolePolicy` 정책이 도입되었습니다. | 2025년 5월 21일 | | [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy)에 권한을 추가했습니다. | VPC CNI가 예기치 않게 종료되는 경우 Amazon EKS가 남아 있는 탄력적 네트워크 인터페이스를 삭제할 수 있도록 `ec2:DeleteNetworkInterfaces` 권한이 추가되었습니다. | 2025년 4월 16일 | | [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)에 권한이 추가되었습니다. | EKS 1.33 버전 릴리스의 일부로 EKS AI/ML 고객이 EFA와 호환되는 기본 EKS 클러스터 SG에 보안 그룹 송신 규칙을 추가할 수 있도록 `ec2:RevokeSecurityGroupEgress` 및 `ec2:AuthorizeSecurityGroupEgress` 권한이 추가되었습니다. | 2025년 4월 14일 | | [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)에 권한이 추가되었습니다. | EKS Auto Mode에서 생성된 EC2 인스턴스를 종료할 수 있는 권한이 추가되었습니다. | 2025년 2월 28일 | | [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy)에 권한을 추가했습니다. | EBS CSI 드라이버에 모든 스냅샷을 복원할 수 있는 권한을 부여하는 새 명령문을 추가했습니다. 이전에 기존 정책에서 허용되었지만, `CreateVolume`에 대한 IAM 처리가 변경되어 새로운 명시적 명령문이 필요합니다. EBS CSI 드라이버가 기존 볼륨에서 태그를 수정할 수 있는 기능이 추가되었습니다. EBS CSI 드라이버는 Kubernetes VolumeAttributesClasses의 파라미터를 통해 기존 볼륨의 태그를 수정할 수 있습니다. EBS CSI 드라이버가 EBS 볼륨에서 빠른 스냅샷 복원(FSR)을 활성화할 수 있는 기능을 추가했습니다. EBS CSI 드라이버는 Kubernetes 스토리지 클래스의 파라미터를 통해 새 볼륨에서 FSR을 활성화할 수 있습니다. | 2025년 1월 13일 | | [AWS 관리형 정책: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)에 권한이 추가되었습니다. | 네트워킹 및 IP 주소 리소스를 나열하고 기술할 수 있도록 `AmazonEKSLoadBalancingPolicy`를 업데이트했습니다. | 2024년 12월 26일 | | [AWS 관리형 정책: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)에 권한이 추가되었습니다. | 중국 리전과의 호환성을 위해 `AWSServiceRoleForAmazonEKSNodegroup`이 업데이트되었습니다. | 2024년 11월 22일 | | [AWS 관리형 정책: AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy)에 권한 추가 | 클러스터 컨트롤 플레인의 AWS Cloud Controller Manager가 각 노드가 있는 가용 영역을 식별할 수 있도록 `AmazonEKSLocalOutpostClusterPolicy`에 대한 `ec2:DescribeAvailabilityZones` 권한이 추가되었습니다. | 2024년 11월 21일 | | [AWS 관리형 정책: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)에 권한이 추가되었습니다. | Amazon EKS 관리형 노드 그룹에서 생성한 인스턴스에서 `ec2:RebootInstances`를 허용하도록 `AWSServiceRoleForAmazonEKSNodegroup` 정책이 업데이트되었습니다. Amazon EC2 리소스에 대한 `ec2:CreateTags` 권한이 제한되었습니다. | 2024년 11월 20일 | | [AWS 관리형 정책: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)에 권한이 추가되었습니다. | EKS가 AWS 관리형 정책 `AmazonEKSServiceRolePolicy`를 업데이트했습니다. EKS 액세스 정책, 로드 밸런서 관리, 자동 클러스터 리소스 정리에 대한 권한이 추가되었습니다. | 2024년 11월 16일 | | [AWS 관리형 정책: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy)를 소개합니다. | EKS가 AWS 관리형 정책 `AmazonEKSComputePolicy`를 업데이트했습니다. `iam:AddRoleToInstanceProfile` 작업에 대한 리소스 권한이 업데이트되었습니다. | 2024년 11월 7일 | | [AWS 관리형 정책: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy)를 소개합니다. | AWS에서는 `AmazonEKSComputePolicy`를 도입했습니다. | 2024년 11월 1일 | | `AmazonEKSClusterPolicy`에 권한 추가 | Amazon EKS가 노드에 토폴로지 정보를 레이블로 연결할 수 있는 `ec2:DescribeInstanceTopology` 권한이 추가되었습니다. | 2024년 11월 1일 | | [AWS 관리형 정책: AmazonEKSBlockStoragePolicy](#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)를 소개합니다. | AWS에서는 `AmazonEKSBlockStoragePolicy`를 도입했습니다. | 2024년 10월 30일 | | [AWS 관리형 정책: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)를 소개합니다. | AWS에서는 `AmazonEKSLoadBalancingPolicy`를 도입했습니다. | 2024년 10월 30일 | | [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)에 권한이 추가되었습니다. | Amazon EKS가 Amazon CloudWatch에 지표를 게시할 수 있는 `cloudwatch:PutMetricData` 권한이 추가되었습니다. | 2024년 10월 29일 | | [AWS 관리형 정책: AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)를 소개합니다. | AWS에서는 `AmazonEKSNetworkingPolicy`를 도입했습니다. | 2024년 10월 28일 | | `AmazonEKSServicePolicy` 및 `AmazonEKSServiceRolePolicy`에 권한을 추가했습니다 | EKS가 보안 그룹 정보를 읽고 관련 태그를 업데이트할 수 있도록 `ec2:GetSecurityGroupsForVpc` 및 연결된 태그 권한이 추가되었습니다. | 2024년 10월 10일 | | [AmazonEKSWorkerNodeMinimalPolicy](#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)를 도입했습니다. | AWS에서는 `AmazonEKSWorkerNodeMinimalPolicy`를 도입했습니다. | 2024년 10월 3일 | | [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)에 권한을 추가했습니다. | Amazon EKS가 Amazon EKS 관리형 Auto Scaling 그룹에서 `AZRebalance`를 일시 중단 및 다시 재개할 수 있도록 `autoscaling:ResumeProcesses` 및 `autoscaling:SuspendProcesses` 권한이 추가되었습니다. | 2024년 8월 21일 | | [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)에 권한을 추가했습니다. | 사용자 계정의 용량 예약을 설명할 수 있는 `ec2:DescribeCapacityReservations` 권한을 Amazon EKS에 추가했습니다. `CAPACITY_BLOCK` 노드 그룹에서 예약된 규모 조정을 설정할 수 있는 `autoscaling:PutScheduledUpdateGroupAction` 권한이 추가되었습니다. | 2024년 6월 27일 | | [AmazonEKS\$1CNI\$1Policy](#security-iam-awsmanpol-amazoneks-cni-policy) – 기존 정책 업데이트 | Amazon EKS에 Kubernetes용 Amazon VPC CNI 플러그인에서 Amazon VPC 서브넷의 사용 가능한 IP 주소 양을 볼 수 있도록 허용하는 `ec2:DescribeSubnets` 권한이 새로 추가되었습니다. VPC CNI는 각 서브넷의 사용 가능한 IP 주소를 사용하여 탄력적 네트워크 인터페이스를 생성할 때 사용 가능한 IP 주소가 가장 많은 서브넷을 선택할 수 있습니다. | 2024년 3월 4일 | | [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy) - 기존 정책에 대한 업데이트 | Amazon EKS에서 EKS Pod Identity를 허용하는 새로운 권한을 추가했습니다. Amazon EKS Pod Identity 에이전트는 노드 역할을 사용합니다. | 2023년 11월 26일 | | [AmazonEFSCSIDriverPolicy](#security-iam-awsmanpol-amazonefscsidriverservicerolepolicy)를 도입했습니다. | AWS에서는 `AmazonEFSCSIDriverPolicy`를 도입했습니다. | 2023년 7월 26일 | | [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy)에 권한을 추가했습니다. | Amazon EKS에서 로드 밸런서를 생성하는 동안 서브넷 자동 검색 중에 AZ 세부 정보를 가져올 수 있는 `ec2:DescribeAvailabilityZones` 권한이 추가되었습니다. | 2023년 2월 7일 | | [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy)의 정책 조건을 업데이트했습니다. | `StringLike` 키 필드에 와일드카드 문자가 있는 잘못된 정책 조건을 제거했습니다. 또한 in-tree 플러그인에서 생성된 볼륨을 EBS CSI 드라이버에서 삭제할 수 있는 새 조건 `ec2:ResourceTag/kubernetes.io/created-for/pvc/name: "*"`를 `ec2:DeleteVolume`에 추가했습니다. | 2022년 11월 17일 | | [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy)에 권한이 추가되었습니다. | 더 나은 사전 조건 검증 및 관리형 수명 주기 제어를 허용하기 위해 `ec2:DescribeVPCAttribute`, `ec2:GetConsoleOutput` 및 `ec2:DescribeSecret`을 추가했습니다. 또한 Outposts의 컨트롤 플레인 Amazon EC2 인스턴스의 배치 제어를 지원하는 `ec2:RunInstances`에 `ec2:DescribePlacementGroups` 및 `"arn:aws:ec2:*:*:placement-group/*"`을 추가했습니다. | 2022년 10월 24일 | | [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy)의 Amazon Elastic Container Registry 권한을 업데이트합니다. | 모든 리소스 부분에서 범위가 지정된 부분으로 `ecr:GetDownloadUrlForLayer` 작업을 이동했습니다. ` arn:aws:ecr:*:*:repository/eks/ ` 리소스를 추가했습니다. ` arn:aws:ecr:` 리소스를 제거했습니다. 이 리소스에는 추가한 ` arn:aws:ecr:*:*:repository/eks/*` 리소스가 적용됩니다. | 2022년 10월 20일 | | [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy)에 권한이 추가되었습니다. | 클러스터 컨트롤 플레인 인스턴스가 일부 `kubelet` 인수를 업데이트할 수 있도록 ` arn:aws:ecr:*:*:repository/kubelet-config-updater` Amazon Elastic Container Registry 리포지토리가 추가되었습니다. | 2022년 8월 31일 | | [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy)가 도입되었습니다. | AWS에서는 `AmazonEKSLocalOutpostClusterPolicy`를 도입했습니다. | 2022년 8월 24일 | | [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy)가 도입되었습니다. | AWS에서는 `AmazonEKSLocalOutpostServiceRolePolicy`를 도입했습니다. | 2022년 8월 23일 | | [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy)를 도입했습니다. | AWS에서는 `AmazonEBSCSIDriverPolicy`를 도입했습니다. | 2022년 4월 4일 | | [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy)에 권한을 추가했습니다. | 인스턴스 수준 속성을 자동으로 검색할 수 있는 Amazon EKS 최적화 AMI를 사용 설정하도록 `ec2:DescribeInstanceTypes`를 추가했습니다. | 2022년 3월 21일 | | [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)에 권한을 추가했습니다. | Amazon EKS가 지표 수집을 사용할 수 있도록 `autoscaling:EnableMetricsCollection` 권한이 추가되었습니다. | 2021년 12월 13일 | | [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy)에 권한을 추가했습니다. | Amazon EKS가 Network Load Balancer에 대한 서비스 연결 역할을 생성하도록 허용하는 `ec2:DescribeAccountAttributes`, `ec2:DescribeAddresses` 및 `ec2:DescribeInternetGateways` 권한이 추가됨. | 2021년 6월 17일 | | Amazon EKS가 변경 사항 추적 시작. | Amazon EKS가 AWS 관리형 정책에 대한 변경 내용 추적을 시작했습니다. | 2021년 6월 17일 | # IAM 문제 해결 이 주제에서는 IAM과 함께 Amazon EKS를 사용하는 동안 발생할 수 있는 몇 가지 일반적 오류와 이를 해결하는 방법을 다룹니다. ## AccessDeniedException AWS API 작업을 직접 호출할 때 `AccessDeniedException`이 발생하면 사용하고 있는 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) 자격 증명에 해당 직접 호출을 수행할 필수 권한이 없는 것입니다. ``` An error occurred (AccessDeniedException) when calling the DescribeCluster operation: User: arn:aws:iam::111122223333:user/user_name is not authorized to perform: eks:DescribeCluster on resource: arn:aws:eks:region:111122223333:cluster/my-cluster ``` 이전 예제 메시지에서 사용자는 Amazon EKS `DescribeCluster` API 작업을 직접 호출할 권한이 없습니다. IAM 보안 주체에게 Amazon EKS 관리 권한을 부여하려면 [Amazon EKS 자격 증명 기반 정책 예제](security-iam-id-based-policy-examples.md) 섹션을 참조하세요. IAM에 자세한 내용은 *IAM 사용 설명서*에서 [정책을 사용하여 액세스 제어](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html)를 참조하세요. ## **컴퓨팅** 탭에서 **노드** 또는 **리소스** 탭에서 아무것도 볼 수 없으며 AWS Management Console에서 오류가 발생합니다. `Your current user or role does not have access to Kubernetes objects on this EKS cluster`라는 콘솔 오류 메시지가 나타날 수 있습니다. AWS Management Console를 함께 사용하는 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) 사용자에게 필요한 권한이 있는지 확인하세요. 자세한 내용은 [필수 권한](view-kubernetes-resources.md#view-kubernetes-resources-permissions) 섹션을 참조하세요. ## aws-auth `ConfigMap`은 클러스터에 대한 액세스 권한을 부여하지 않습니다. [AWS IAM Authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator)는 `ConfigMap`에 사용된 역할 ARN의 경로를 허용하지 않습니다. 따라서 `rolearn`를 지정하기 전에 경로를 제거하세요. 예를 들면 ` arn:aws:iam::111122223333:role/team/developers/eks-admin `를 ` arn:aws:iam::111122223333:role/eks-admin `로 변경합니다. ## iam:PassRole을 수행하도록 인증되지 않음 `iam:PassRole` 작업을 수행할 수 있는 권한이 없다는 오류가 수신되면 Amazon EKS에 역할을 전달할 수 있도록 정책을 업데이트해야 합니다. 일부 AWS 서비스에서는 새 서비스 역할 또는 서비스 연결 역할을 생성하는 대신, 해당 서비스에 기존 역할을 전달할 수 있습니다. 이렇게 하려면 사용자가 서비스에 역할을 전달할 수 있는 권한을 가지고 있어야 합니다. 다음 예제 오류는 `marymajor`라는 IAM 사용자가 콘솔을 사용하여 Amazon EKS에서 작업을 수행하려고 하는 경우에 발생합니다. 하지만 작업을 수행하려면 서비스 역할이 부여한 권한이 서비스에 있어야 합니다. Mary는 서비스에 역할을 전달할 수 있는 권한을 가지고 있지 않습니다. ``` User: {arn-aws}iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` 이 경우, Mary가 `iam:PassRole` 작업을 수행할 수 있도록 Mary의 정책을 업데이트해야 합니다. 도움이 필요한 경우 AWS 관리자에게 문의하세요. 관리자는 로그인 자격 증명을 제공한 사람입니다. ## 내 AWS 계정 외부의 사용자가 내 Amazon EKS 리소스에 액세스하도록 허용하려고 합니다. 다른 계정의 사용자 또는 조직 외부의 사람이 리소스에 액세스할 때 사용할 수 있는 역할을 생성할 수 있습니다. 역할을 수임할 신뢰할 수 있는 사람을 지정할 수 있습니다. 리소스 기반 정책 또는 액세스 제어 목록(ACL)을 지원하는 서비스의 경우, 이러한 정책을 사용하여 다른 사람에게 리소스에 대한 액세스 권한을 부여할 수 있습니다. 자세한 내용은 다음을 참조하세요. + Amazon EKS에서 이러한 기능을 지원하는지 알아보려면 [Amazon EKS가 IAM과 작동하는 방식](security-iam-service-with-iam.md) 섹션을 참조하세요. + 소유하고 있는 AWS 계정의 리소스에 대한 액세스 권한을 제공하는 방법을 알아보려면 *IAM 사용 설명서*의 [자신이 소유한 다른 AWS 계정의 IAM 사용자에 대한 액세스 권한 제공](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)을 참조하세요. + 리소스에 대한 액세스 권한을 서드 파티 AWS 계정에게 제공하는 방법을 알아보려면 *IAM 사용 설명서의 [서드 파티](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)가 소유한 AWS 계정에 대한 액세스 제공*을참조하세요. + ID 페더레이션을 통해 액세스 권한을 제공하는 방법을 알아보려면 *IAM 사용 설명서*의 [외부에서 인증된 사용자에게 액세스 권한 제공(ID 페더레이션)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)을 참조하세요. + 크로스 계정 액세스에 대한 역할과 리소스 기반 정책 사용의 차이점을 알아보려면 *IAM 사용 설명서*의 [IAM의 크로스 계정 리소스 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)를 참조하세요. ## 포드 컨테이너는 다음과 같은 오류가 발생합니다. `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region` 애플리케이션이 명시적으로 AWS STS 글로벌 엔드포인트(`https://sts.amazonaws`)를 요청하고 Kubernetes 서비스 계정이 리전별 엔드포인트를 사용하도록 구성된 경우 컨테이너에 이 오류가 표시됩니다. 다음 옵션 중 하나를 사용하여 문제를 해결할 수 있습니다. + 애플리케이션 코드를 업데이트하여 AWS STS 전역 엔드포인트에 대한 명시적 직접 호출을 제거합니다. + 애플리케이션 코드를 업데이트하여 `https://sts.us-west-2.amazonaws.com`와 같은 리전별 엔드포인트를 명시적으로 직접 호출합니다. 애플리케이션에는 해당 AWS 리전에서 서비스 장애가 발생한 경우 다른 AWS 리전을 선택하기 위해 기본 제공되는 중복성이 있어야 합니다. 자세한 내용은 IAM 사용 설명서의 [AWS 리전에서 AWS STS 관리](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)를 참조하세요. + 전역 엔드포인트를 사용하도록 서비스 계정을 구성합니다. 클러스터는 기본적으로 리전 엔드포인트를 사용합니다. 자세한 내용은 [서비스 계정의 AWS 보안 토큰 서비스 엔드포인트 구성](configure-sts-endpoint.md) 섹션을 참조하세요. # Amazon EKS 클러스터 IAM 역할 각 클러스터에는 Amazon EKS 클러스터 IAM 역할이 필요합니다. Amazon EKS에서 관리하는 Kubernetes 클러스터는 이 역할을 사용하여 노드를 관리하고, [레거시 클라우드 제공업체](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)는 이 역할을 사용하여 서비스용 Elastic Load Balancing으로 로드 밸런서를 생성합니다. Amazon EKS 클러스터를 생성하기 전에 다음 IAM 정책 중 하나를 사용하여 IAM 역할을 생성해야 합니다. + [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) + 사용자 지정 IAM 정책. 다음 최소 권한으로는 Kubernetes 클러스터가 노드를 관리할 수 있지만, [레거시 클라우드 제공업체](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)가 Elastic Load Balancing으로 로드 밸런서를 생성하는 것은 허용되지 않습니다. 사용자 지정 IAM 정책에는 적어도 다음과 같은 권한이 있어야 합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "ForAnyValue:StringLike": { "aws:TagKeys": "kubernetes.io/cluster/*" } } }, { "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcs", "ec2:DescribeDhcpOptions", "ec2:DescribeAvailabilityZones", "ec2:DescribeInstanceTopology", "kms:DescribeKey" ], "Resource": "*" } ] } ``` **참고** 2023년 10월 3일 이전에는 각 클러스터의 IAM 역할에 [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html)이 필요했습니다. 2020년 4월 16일 이전에는 [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) 및 [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html)도 필요했으며 제안된 이름은 `eksServiceRole`이었습니다. `AWSServiceRoleForAmazonEKS` 서비스 연결 역할을 사용하면 2020년 4월 16일 이후에 생성된 클러스터에 [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) 정책이 더 이상 필요하지 않습니다. ## 기존 클러스터 역할 확인 다음 절차를 사용하여 계정에 이미 Amazon EKS 클러스터 역할이 있는지 확인할 수 있습니다. 1. IAM 콘솔(https://console.aws.amazon.com/iam/)을 엽니다. 1. 왼쪽 탐색 창에서 **역할**을 선택합니다. 1. 역할 목록에서 `eksClusterRole`(을)를 검색합니다. `eksClusterRole`을 포함하는 역할이 존재하지 않을 경우 [Amazon EKS 클러스터 역할 생성](#create-service-role) 섹션을 참조하여 역할을 생성합니다. `eksClusterRole`을 포함하는 역할이 존재하지 않을 경우, 연결된 정책을 볼 역할을 선택합니다. 1. **권한**을 선택합니다. 1. **AmazonEKSClusterPolicy** 관리형 정책이 역할에 연결되었는지 확인합니다. 정책이 연결된 경우 Amazon EKS 클러스터 역할이 적절히 구성된 것입니다. 1. **신뢰 관계**를 선택한 후 **신뢰 정책 편집**을 선택합니다. 1. 신뢰 관계에 다음 정책이 포함되어 있는지 확인합니다. 신뢰 관계가 다음 정책과 일치하는 경우, **취소**를 선택합니다. 신뢰 관계가 일치하지 않으면 정책을 **신뢰 정책 편집** 창에 복사하고 **정책 업데이트**를 선택합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ## Amazon EKS 클러스터 역할 생성 클러스터 역할을 생성하려면 AWS Management Console 또는 AWS CLI를 사용할 수 있습니다. AWS Management Console 1. IAM 콘솔(https://console.aws.amazon.com/iam/)을 엽니다. 1. **역할**을 선택한 다음 **역할 생성**을 선택합니다. 1. **신뢰할 수 있는 엔터티 유형**에서 ** AWS서비스**를 선택합니다. 1. **다른 AWS 서비스의 사용 사례** 드롭다운 목록에서 **EKS**를 선택합니다. 1. 사용 사례에 대한 **EKS - 클러스터(EKS - Cluster)**를 선택한 후 **다음**을 선택합니다. 1. **권한 추가** 탭에서 **다음**을 선택합니다. 1. **역할 이름**에 역할의 고유한 이름(예: `eksClusterRole`)을 입력합니다. 1. **설명**에서 `Amazon EKS - Cluster role`과 같은 설명 텍스트를 입력합니다. 1. **역할 생성**을 선택합니다. AWS CLI 1. 다음 콘텐츠를 *cluster-trust-policy.json*라는 파일에 복사합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. 역할을 생성합니다. *eksClusterRole*을 선택한 모든 이름으로 바꿀 수 있습니다. ``` aws iam create-role \ --role-name eksClusterRole \ --assume-role-policy-document file://"cluster-trust-policy.json" ``` 1. 필요한 IAM 정책을 역할에 연결합니다. ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy \ --role-name eksClusterRole ``` # Amazon EKS 노드 IAM 역할 Amazon EKS 노드 `kubelet` 대몬은 사용자를 대신하여 AWS API를 직접 호출합니다. 노드는 IAM 인스턴스 프로필 및 연결 정책을 통해 이 API 직접 호출에 대한 권한을 수신합니다. 노드를 시작해 클러스터에 등록하려면 시작할 때 노드에서 사용할 IAM 역할을 생성해야 합니다. 이 요구 사항은 Amazon이 제공하는 Amazon EKS 최적화 AMI 또는 사용하려는 다른 노드 AMI를 사용하여 시작된 노드에 적용됩니다. 또한 이 요구 사항은 관리형 노드 그룹과 자체 관리형 노드 모두에 적용됩니다. **참고** 클러스터를 생성하는 데 사용된 것과 동일한 역할을 사용할 수 없습니다. 노드를 생성하려면 먼저 다음 권한을 사용하여 IAM 역할을 생성해야 합니다. + [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html) 정책에서 제공하는 것과 같이 VPC의 Amazon EC2 리소스를 설명할 수 있는 `kubelet` 권한. 이 정책은 Amazon EKS Pod Identity 에이전트에 대한 권한도 제공합니다. + Amazon Elastic Container Registry(Amazon ECR)의 컨테이너 이미지를 사용할 수 있는 `kubelet` 권한([AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html) 정책에서 제공하는 권한). 네트워킹용 내장 애드온이 Amazon ECR의 컨테이너 이미지를 사용하는 포드를 실행하기 때문에 Amazon Elastic Container Registry(Amazon ECR)의 컨테이너 이미지를 사용할 수 있는 권한이 필요합니다. + (선택사항) Amazon EKS Pod Identity 에이전트에서 `eks-auth:AssumeRoleForPodIdentity` 작업을 사용하여 포드에 대한 보안 인증 정보를 검색할 수 있는 권한. [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html)를 사용하지 않는 경우 EKS Pod Identity를 사용할 수 있는 EC2 권한 외에도 이 권한을 제공해야 합니다. + (선택 사항) IRSA 또는 EKS Pod Identity를 사용하여 VPC CNI 포드에 권한을 부여하지 않는 경우 인스턴스 역할에서 VPC CNI에 대한 권한을 제공해야 합니다. [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) 관리형 정책(`IPv4` 제품군으로 클러스터를 생성하는 경우) 또는 [사용자가 생성한 IPv6 정책](cni-iam-role.md#cni-iam-role-create-ipv6-policy)(`IPv6` 제품군으로 클러스터를 생성하는 경우)을 사용할 수 있습니다. 그러나 이 역할에 정책을 연결하는 대신 Amazon VPC CNI 추가 기능에 특별히 사용되는 별도의 역할에 정책을 연결하는 것이 좋습니다. Amazon VPC CNI 추가 기능에 대한 별도의 역할 생성에 대한 자세한 내용은 [IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성](cni-iam-role.md) 섹션을 참조하세요. **참고** Amazon EC2 노드 그룹에는 Fargate 프로필과 다른 IAM 역할이 있어야 합니다. 자세한 내용은 [Amazon EKS 포드 실행 IAM 역할](pod-execution-role.md) 섹션을 참조하세요. ## 기존 노드 역할 확인 다음 절차를 사용하여 계정에 이미 Amazon EKS 노드 역할이 있는지 확인할 수 있습니다. 1. IAM 콘솔(https://console.aws.amazon.com/iam/)을 엽니다. 1. 왼쪽 탐색 창에서 **역할**을 선택합니다. 1. 역할 목록에서 `eksNodeRole`, `AmazonEKSNodeRole` 또는 `NodeInstanceRole`을 검색합니다. 이러한 이름 중 하나를 가진 역할이 없으면 [Amazon EKS 노드 IAM 역할 생성](#create-worker-node-role) 섹션을 참조하여 역할을 만듭니다. `eksNodeRole`, `AmazonEKSNodeRole` 또는 `NodeInstanceRole`을 포함하는 역할이 존재하는 경우 역할을 선택하여 연결된 정책을 확인합니다. 1. **권한**을 선택합니다. 1. **AmazonEKSWorkerNodePolicy** 및 **AmazonEC2ContainerRegistryPullOnly** 관리형 정책이 역할에 연결되어 있는지 또는 사용자 지정 정책이 최소 권한으로 연결되어 있는지 확인합니다. **참고** **AmazonEKS\$1CNI\$1Policy** 정책이 역할에 연결되어 있는 경우 해당 역할을 제거하고 대신 `aws-node` Kubernetes 서비스 계정에 매핑된 IAM 역할에 연결하는 것이 좋습니다. 자세한 내용은 [IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성](cni-iam-role.md) 섹션을 참조하세요. 1. **신뢰 관계**를 선택한 후 **신뢰 정책 편집**을 선택합니다. 1. 신뢰 관계에 다음 정책이 포함되어 있는지 확인합니다. 신뢰 관계가 다음 정책과 일치하는 경우, **취소**를 선택합니다. 신뢰 관계가 일치하지 않으면 정책을 **신뢰 정책 편집** 창에 복사하고 **정책 업데이트**를 선택합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Principal": { "Service": [ "ec2.amazonaws.com" ] } } ] } ``` ## Amazon EKS 노드 IAM 역할 생성 AWS Management Console 또는 AWS CLI를 사용하여 노드 IAM 역할을 생성할 수 있습니다. AWS Management Console 1. IAM 콘솔(https://console.aws.amazon.com/iam/)을 엽니다. 1. 왼쪽 탐색 창에서 **역할**을 선택합니다. 1. **역할** 페이지에서 **역할 생성**을 선택합니다. 1. **신뢰할 수 있는 엔터티 선택** 페이지에서 다음을 수행합니다. 1. **신뢰할 수 있는 엔터티 유형** 섹션에서 **AWS 서비스**를 선택합니다. 1. **사용 사례**에서 **EC2**를 선택합니다. 1. **다음**을 선택합니다. 1. **권한 추가** 페이지에서 사용자 지정 정책을 연결하거나 다음과 같이 합니다. 1. **필터 정책** 상자에 `AmazonEKSWorkerNodePolicy`를 입력합니다. 1. 검색 결과의 **AmazonEKSWorkerNodePolicy** 왼쪽에 있는 확인란을 선택합니다. 1. **필터 지우기**를 선택합니다. 1. **필터 정책** 상자에 `AmazonEC2ContainerRegistryPullOnly`를 입력합니다. 1. 검색 결과의 **AmazonEC2ContainerRegistryPullOnly** 왼쪽에 있는 확인란을 선택합니다. 생성하는 **AmazonEKS\$1CNI\$1Policy** 관리형 정책이나 [IPv6 정책](cni-iam-role.md#cni-iam-role-create-ipv6-policy)은 또한 이 역할이나 `aws-node` Kubernetes 서비스 계정에 매핑된 다른 역할에 연결되어야 합니다. 이 역할에 정책을 할당하는 대신 Kubernetes 서비스 계정에 연결된 역할에 정책을 할당하는 것이 좋습니다. 자세한 내용은 [IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성](cni-iam-role.md) 섹션을 참조하세요. 1. **다음**을 선택합니다. 1. **이름, 검토 및 생성** 페이지에서 다음을 수행합니다. 1. **역할 이름**에 역할의 고유한 이름(예: `AmazonEKSNodeRole`)을 입력합니다. 1. **설명**에서 현재 텍스트를 설명이 포함된 텍스트(예: `Amazon EKS - Node role`)로 바꿉니다. 1. **태그 추가(선택사항)**에서 태그를 키-값 페어로 연결하여 메타데이터를 역할에 추가합니다. IAM에서 태그 사용에 대한 자세한 내용을 알아보려면 IAM 사용 설명서의 [IAM 리소스에 태깅](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)을 참조하세요. 1. **역할 생성**을 선택합니다. AWS CLI 1. 다음 명령을 실행해 `node-role-trust-relationship.json` 파일을 생성합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Principal": { "Service": [ "ec2.amazonaws.com" ] } } ] } ``` 1. IAM 역할을 생성합니다. ``` aws iam create-role \ --role-name AmazonEKSNodeRole \ --assume-role-policy-document file://"node-role-trust-relationship.json" ``` 1. 필요한 2개의 관리형 IAM 정책을 IAM 역할에 연결합니다. ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \ --role-name AmazonEKSNodeRole aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly \ --role-name AmazonEKSNodeRole ``` 1. 클러스터를 생성한 IP 패밀리에 따라 다음 IAM 정책 중 하나를 IAM 역할에 연결합니다. 이 정책은 이 역할에 연결되거나, Kubernetes용 Amazon VPC CNI 플러그인에 사용되는 Kubernetes `aws-node` 서비스 계정에 연결된 역할에 연결되어야 합니다. Kubernetes 서비스 계정에 연결된 역할에 정책을 할당하는 것이 좋습니다. Kubernetes 서비스 계정에 연결된 역할에 정책을 할당하려면 [IRSA를 사용하도록 Amazon VPC CNI 플러그인 구성](cni-iam-role.md) 섹션을 참조하세요. + IPv4 ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \ --role-name AmazonEKSNodeRole ``` + IPv6 1. 다음 텍스트를 복사해 `vpc-cni-ipv6-policy.json` 파일에 저장합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:AssignIpv6Addresses", "ec2:DescribeInstances", "ec2:DescribeTags", "ec2:DescribeNetworkInterfaces", "ec2:DescribeInstanceTypes" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": [ "arn:aws:ec2:*:*:network-interface/*" ] } ] } ``` 1. IAM 정책을 생성합니다. ``` aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json ``` 1. IAM 정책을 IAM 역할에 연결합니다. *111122223333*을 계정 ID로 바꿉니다. ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy \ --role-name AmazonEKSNodeRole ``` # Amazon EKS Auto Mode 클러스터 IAM 역할 클러스터마다 Amazon EKS 클러스터 IAM 역할이 필요합니다. Amazon EKS에서 관리하는 Kubernetes 클러스터는 이 역할을 사용하여 스토리지, 네트워킹, 컴퓨팅 오토 스케일링에 대한 일상적인 태스크를 자동화합니다. Amazon EKS 클러스터를 생성하려면 먼저 EKS Auto Mode에 필요한 정책을 사용하여 IAM 역할을 만들어야 합니다. 제안된 AWS IAM 관리형 정책을 연결하거나 동등한 권한을 보유한 사용자 지정 정책을 생성할 수 있습니다. + [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy) + [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy) + [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy) + [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy) + [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) ## 기존 클러스터 역할 확인 다음 절차를 사용하여 계정에 이미 Amazon EKS 클러스터 역할이 있는지 확인할 수 있습니다. 1. IAM 콘솔(https://console.aws.amazon.com/iam/)을 엽니다. 1. 왼쪽 탐색 창에서 **역할**을 선택합니다. 1. 역할 목록에서 `AmazonEKSAutoClusterRole`(을)를 검색합니다. `AmazonEKSAutoClusterRole`을 포함하는 역할이 존재하지 않을 경우 다음 섹션의 지침을 참조하여 역할을 생성합니다. `AmazonEKSAutoClusterRole`을 포함하는 역할이 존재하지 않을 경우, 연결된 정책을 볼 역할을 선택합니다. 1. **권한**을 선택합니다. 1. **AmazonEKSClusterPolicy** 관리형 정책이 역할에 연결되었는지 확인합니다. 정책이 연결된 경우 Amazon EKS 클러스터 역할이 적절히 구성된 것입니다. 1. **신뢰 관계**를 선택한 후 **신뢰 정책 편집**을 선택합니다. 1. 신뢰 관계에 다음 정책이 포함되어 있는지 확인합니다. 신뢰 관계가 다음 정책과 일치하는 경우, **취소**를 선택합니다. 신뢰 관계가 일치하지 않으면 정책을 **신뢰 정책 편집** 창에 복사하고 **정책 업데이트**를 선택합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` **참고** AWS에는 이 역할의 이름 `AmazonEKSAutoClusterRole`이 필요하지 않습니다. ## Amazon EKS 클러스터 역할 생성 클러스터 역할을 생성하려면 AWS Management Console 또는 AWS CLI를 사용할 수 있습니다. ### AWS Management Console 1. IAM 콘솔(https://console.aws.amazon.com/iam/)을 엽니다. 1. **역할**을 선택한 다음 **역할 생성**을 선택합니다. 1. **신뢰할 수 있는 엔터티 유형**에서 ** AWS서비스**를 선택합니다. 1. **다른 AWS 서비스의 사용 사례** 드롭다운 목록에서 **EKS**를 선택합니다. 1. 사용 사례에 대한 **EKS - 클러스터(EKS - Cluster)**를 선택한 후 **다음**을 선택합니다. 1. **권한 추가** 탭에서 정책을 선택하고 **다음**을 선택합니다. + [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy) + [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy) + [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy) + [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy) + [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) 1. **역할 이름**에 역할의 고유한 이름(예: `AmazonEKSAutoClusterRole`)을 입력합니다. 1. **설명**에서 `Amazon EKS - Cluster role`과 같은 설명 텍스트를 입력합니다. 1. **역할 생성**을 선택합니다. ### AWS CLI 1. 다음 콘텐츠를 *cluster-trust-policy.json*라는 파일에 복사합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` 1. 역할을 생성합니다. *AmazonEKSAutoClusterRole*을 선택한 이름으로 바꿀 수 있습니다. ``` aws iam create-role \ --role-name AmazonEKSAutoClusterRole \ --assume-role-policy-document file://"cluster-trust-policy.json" ``` 1. 필요한 IAM 정책을 역할에 연결합니다. **AmazonEKSClusterPolicy**: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy ``` **AmazonEKSComputePolicy**: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSComputePolicy ``` **AmazonEKSBlockStoragePolicy**: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSBlockStoragePolicy ``` **AmazonEKSLoadBalancingPolicy**: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSLoadBalancingPolicy ``` **AmazonEKSNetworkingPolicy**: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSNetworkingPolicy ``` # Amazon EKS Auto Mode 노드 IAM 역할 **참고** 클러스터를 생성하는 데 사용된 것과 동일한 역할을 사용할 수 없습니다. 노드를 생성하려면 먼저 다음 정책 또는 이와 동등한 권한을 사용하여 IAM 역할을 생성해야 합니다. + [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy) + [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly) ## 기존 노드 역할 확인 다음 절차를 사용하여 계정에 이미 Amazon EKS 노드 역할이 있는지 확인할 수 있습니다. 1. IAM 콘솔(https://console.aws.amazon.com/iam/)을 엽니다. 1. 왼쪽 탐색 창에서 **역할**을 선택합니다. 1. 역할 목록에서 `AmazonEKSAutoNodeRole`(을)를 검색합니다. 이러한 이름 중 하나를 가진 역할이 없으면 다음 섹션의 지침을 참조하여 역할을 만듭니다. `AmazonEKSAutoNodeRole`을 포함하는 역할이 존재하지 않을 경우, 연결된 정책을 볼 역할을 선택합니다. 1. **권한**을 선택합니다. 1. 위의 필수 정책 또는 이에 상응하는 사용자 지정 정책이 연결되어 있는지 확인합니다. 1. **신뢰 관계**를 선택한 후 **신뢰 정책 편집**을 선택합니다. 1. 신뢰 관계에 다음 정책이 포함되어 있는지 확인합니다. 신뢰 관계가 다음 정책과 일치하는 경우, **취소**를 선택합니다. 신뢰 관계가 일치하지 않으면 정책을 **신뢰 정책 편집** 창에 복사하고 **정책 업데이트**를 선택합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ## Amazon EKS 노드 IAM 역할 생성 AWS Management Console 또는 AWS CLI를 사용하여 노드 IAM 역할을 생성할 수 있습니다. ### AWS Management Console 1. IAM 콘솔(https://console.aws.amazon.com/iam/)을 엽니다. 1. 왼쪽 탐색 창에서 **역할**을 선택합니다. 1. **역할** 페이지에서 **역할 생성**을 선택합니다. 1. **신뢰할 수 있는 엔터티 선택** 페이지에서 다음을 수행합니다. 1. **신뢰할 수 있는 엔터티 유형** 섹션에서 **AWS 서비스**를 선택합니다. 1. **사용 사례**에서 **EC2**를 선택합니다. 1. **다음**을 선택합니다. 1. **권한 추가** 페이지에서 다음 정책을 연결합니다. + [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy) + [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly) 1. **이름, 검토 및 생성** 페이지에서 다음을 수행합니다. 1. **역할 이름**에 역할의 고유한 이름(예: `AmazonEKSAutoNodeRole`)을 입력합니다. 1. **설명**에서 현재 텍스트를 설명이 포함된 텍스트(예: `Amazon EKS - Node role`)로 바꿉니다. 1. **태그 추가(선택사항)**에서 태그를 키-값 페어로 연결하여 메타데이터를 역할에 추가합니다. IAM에서 태그 사용에 대한 자세한 내용을 알아보려면 IAM 사용 설명서의 [IAM 리소스에 태깅](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)을 참조하세요. 1. **역할 생성**을 선택합니다. ### AWS CLI **노드 IAM 역할 생성** 이전 단계의 **node-trust-policy.json** 파일을 사용하여 역할을 수임할 수 있는 엔터티를 정의합니다. 다음 명령을 실행하여 노드 IAM 역할을 만듭니다. ``` aws iam create-role \ --role-name AmazonEKSAutoNodeRole \ --assume-role-policy-document file://node-trust-policy.json ``` **역할 ARN 기록** 역할을 생성한 후 노드 IAM 역할의 ARN을 검색하고 저장합니다. 이후 단계에서 이 ARN이 필요합니다. 다음 명령을 사용하여 ARN을 가져옵니다. ``` aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text ``` **필요한 정책 연결** 다음 AWS 관리형 정책을 노드 IAM 역할에 연결하여 필요한 권한을 제공합니다. AmazonEKSWorkerNodeMinimalPolicy를 연결하려면: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoNodeRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy ``` AmazonEC2ContainerRegistryPullOnly를 연결하려면: ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoNodeRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly ``` # Amazon EKS 기능 IAM 역할 EKS 기능을 사용하려면 기능 IAM 역할 또는 기능 역할을 구성해야 합니다. 기능은 이 역할을 사용하여 AWS 서비스에서 작업을 수행하고 자동으로 생성된 액세스 항목을 통해 클러스터의 Kubernetes 리소스에 액세스합니다. 기능 생성 중에 기능 역할을 지정하려면 먼저 기능 유형에 대한 적절한 신뢰 정책 및 권한을 사용하여 IAM 역할을 생성해야 합니다. 이 IAM 역할이 생성되면 원하는 수의 기능 리소스에 대해 재사용할 수 있습니다. ## 기능 역할 요구 사항 기능 역할은 다음 요구 사항을 충족해야 합니다. + 역할은 클러스터 및 기능 리소스와 동일한 AWS 계정에 있어야 함 + 역할에는 EKS 기능 서비스가 역할을 수임하도록 허용하는 신뢰 정책이 있어야 함 + 역할에는 기능 유형 및 사용 사례 요구 사항에 적절한 권한이 있어야 함([기능 유형별 권한](#capability-permissions) 참조) ## 기능 역할에 대한 신뢰 정책 모든 기능 역할에는 다음 신뢰 정책이 포함되어야 합니다. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "capabilities.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` 이 신뢰 정책을 통해 EKS는 다음을 수행할 수 있습니다. + AWS API 작업을 수행하도록 역할 수임 + 감사 및 추적을 위해 세션에 태그 지정 ## 기능 유형별 권한 필요한 IAM 권한은 사용 중인 기능 및 배포 모델에 따라 다릅니다. **참고** ACK와 함께 IAM 역할 선택기를 사용하는 프로덕션 배포의 경우 또는 AWS 서비스 통합 없이 kro 또는 Argo CD를 사용하는 경우 기능 역할에는 신뢰 정책 이외의 IAM 권한이 필요하지 않을 수 있습니다. **Kube Resource Orchestrator(kro)** IAM 권한이 필요하지 않습니다. 연결된 정책 없이 기능 역할을 생성할 수 있습니다. kro는 Kubernetes 리소스를 생성 및 관리하는 데 Kubernetes RBAC 권한만 필요합니다. **AWS Controllers for Kubernetes(ACK)** ACK는 다음과 같이 두 가지 권한 모델을 지원합니다. + **단순 설정(개발/테스트)**: 기능 역할에 직접 AWS 서비스 권한을 추가합니다. 시작하기, 단일 계정 배포 또는 모든 사용자에게 동일한 권한이 필요한 경우에 적합합니다. + **프로덕션 모범 사례**: IAM 역할 선택기를 사용하여 최소 권한 액세스를 구현합니다. 이 접근 방식을 사용하면 기능 역할에는 서비스 특정 역할을 수임할 `sts:AssumeRole` 권한만 있으면 됩니다. 기능 역할 자체에 AWS 서비스 권한(예: S3 또는 RDS)을 추가하지 않아도 됩니다. 이러한 권한은 특정 네임스페이스에 매핑되는 개별 IAM 역할에 부여됩니다. IAM 역할 선택기는 다음을 활성화합니다. + 네임스페이스 수준의 권한 격리 + 교차 계정 리소스 관리 + 팀 특정 IAM 역할 + 최소 권한 보안 모델 IAM 역할 선택기 접근 방식에 대한 기능 역할 정책 예제: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::111122223333:role/ACK-S3-Role", "arn:aws:iam::111122223333:role/ACK-RDS-Role", "arn:aws:iam::444455556666:role/ACKCrossAccountRole" ] } ] } ``` IAM 역할 선택기를 포함한 자세한 ACK 권한 구성은 [ACK 권한 구성](ack-permissions.md) 섹션을 참조하세요. **Argo CD** 기본적으로 IAM 권한은 필요하지 않습니다. 다음과 같은 경우에 선택적 권한이 필요할 수 있습니다. + **AWS Secrets Manager**: Secrets Manager를 사용하여 Git 리포지토리 자격 증명을 저장하는 경우 + **AWS CodeConnections**: Git 리포지토리 인증에 CodeConnections를 사용하는 경우 Secrets Manager 및 CodeConnections에 대한 정책 예제: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": "arn:aws:secretsmanager:region:account-id:secret:argocd/*" }, { "Effect": "Allow", "Action": [ "codeconnections:UseConnection", "codeconnections:GetConnection" ], "Resource": "arn:aws:codeconnections:region:account-id:connection/*" } ] } ``` 자세한 Argo CD 권한 요구 사항은 [Argo CD 고려 사항](argocd-considerations.md) 섹션을 참조하세요. ## 기존 기능 역할 확인 다음 절차를 사용하여 사용 사례에 적합한 기능 IAM 역할이 이미 계정에 있는지 확인할 수 있습니다. 1. IAM 콘솔(https://console.aws.amazon.com/iam/)을 엽니다. 1. 왼쪽 탐색 창에서 **역할**을 선택합니다. 1. 역할 목록에서 기능 역할 이름(예: `ACKCapabilityRole` 또는 `ArgoCDCapabilityRole`)을 검색하세요. 1. 역할이 있는 경우 역할을 선택하여 연결된 정책 및 신뢰 관계를 확인하세요. 1. **신뢰 관계**를 선택한 후 **신뢰 정책 편집**을 선택합니다. 1. 신뢰 관계가 [기능 신뢰 정책](#capability-trust-policy)과 일치하는지 확인하세요. 일치하지 않는 경우 신뢰 정책을 업데이트하세요. 1. **권한**을 선택하고 역할에 기능 유형 및 사용 사례에 적합한 권한이 있는지 확인하세요. ## 기능 IAM 역할 생성 기능 역할을 생성하기 위해 AWS Management Console 또는 AWS CLI를 사용할 수 있습니다. ** AWS Management Console ** 1. IAM 콘솔(https://console.aws.amazon.com/iam/)을 엽니다. 1. **역할**을 선택한 다음 **역할 생성**을 선택합니다. 1. **신뢰할 수 있는 엔터티 유형**에서 **사용자 지정 신뢰 정책**을 선택하세요. 1. [기능 신뢰 정책](#capability-trust-policy) 복사하여 신뢰 정책 편집기에 붙여 넣으세요. 1. **다음**을 선택합니다. 1. **권한 추가** 탭에서 기능 유형에 적합한 정책을 선택하거나 생성하세요([기능 유형별 권한](#capability-permissions) 참조). kro의 경우 이 단계를 건너뛸 수 있습니다. 1. **다음**을 선택합니다. 1. **역할 이름**에 역할의 고유한 이름(예: `ACKCapabilityRole`, `ArgoCDCapabilityRole` 또는 `kroCapabilityRole`)을 입력하세요. 1. **설명**에서 `Amazon EKS - ACK capability role`과 같은 설명 텍스트를 입력합니다. 1. **역할 생성**을 선택합니다. **AWS CLI** 1. [기능 신뢰 정책](#capability-trust-policy)을 `capability-trust-policy.json` 파일에 복사하세요. 1. 역할을 생성합니다. `ACKCapabilityRole`을 원하는 역할 이름으로 바꾸세요. ``` aws iam create-role \ --role-name ACKCapabilityRole \ --assume-role-policy-document file://capability-trust-policy.json ``` 1. 필요한 IAM 정책을 역할에 연결하세요. ACK의 경우 관리하려는 AWS 서비스에 대한 정책을 연결하세요. Argo CD의 경우 필요하면 Secrets Manager 또는 CodeConnections에 대한 정책을 연결하세요. kro의 경우 이 단계를 건너뛸 수 있습니다. S3 권한을 사용하는 ACK에 대한 예제: ``` aws iam put-role-policy \ --role-name ACKCapabilityRole \ --policy-name S3Management \ --policy-document file://s3-policy.json ``` ## 기능 역할 문제 해결 **'유효하지 않은 IAM 역할'로 기능 생성 실패** 다음을 확인합니다. + 역할이 클러스터와 동일한 계정에 존재함 + 신뢰 정책이 [기능 신뢰 정책](#capability-trust-policy)과 일치함 + 역할에 대한 `iam:PassRole` 권한이 있음 **기능에서 권한 오류 표시** 다음을 확인합니다. + 기능 역할에 필요한 권한이 해당 역할에 있음 + 액세스 항목이 역할의 클러스터에 있음 + 필요한 경우 추가 Kubernetes 권한이 구성됨([추가 Kubernetes 권한](capabilities-security.md#additional-kubernetes-permissions) 참조) **'권한 거부' 오류로 ACK 리소스 실패** 다음을 확인합니다. + 역할에는 사용 사례에 필요한 권한이 있습니다. + 보안 암호를 참조하는 ACK 컨트롤러의 경우 적절한 네임스페이스로 범위가 지정된 `AmazonEKSSecretReaderPolicy` 액세스 항목 정책을 연결했는지 확인합니다. 문제 해결 지침은 [EKS 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요.