EKS Pod Identity가 Pod에 AWS 서비스 액세스 권한을 부여하는 방법 알아보기

EKS Pod Identity를 사용해 Pod에 AWS 서비스 액세스 권한을 부여하는 방법, 이점, 한계를 설명합니다.

출처: 문서

본문

Pod의 컨테이너에 있는 애플리케이션은 AWS SDK나 AWS CLI를 사용해 AWS Identity and Access Management(IAM) 권한으로 AWS 서비스에 API 요청을 할 수 있습니다. 애플리케이션은 AWS API 요청에 AWS 자격 증명으로 서명해야 합니다.

EKS Pod Identity는 Amazon EC2 인스턴스 프로파일이 Amazon EC2 인스턴스에 자격 증명을 제공하는 방식과 유사하게, 애플리케이션의 자격 증명을 관리하는 기능을 제공합니다. AWS 자격 증명을 생성해 컨테이너에 배포하거나 Amazon EC2 인스턴스의 역할을 사용하는 대신, IAM 역할을 Kubernetes 서비스 계정과 연결하고 Pod를 해당 서비스 계정을 사용하도록 구성합니다.

각 EKS Pod Identity 연결(association)은 지정된 클러스터의 네임스페이스에 있는 서비스 계정에 역할을 매핑합니다. 동일한 애플리케이션이 여러 클러스터에 있다면, 역할의 신뢰 정책을 수정하지 않고도 각 클러스터에서 동일한 연결을 만들 수 있습니다.

Pod가 연결된 서비스 계정을 사용한다면 Amazon EKS는 Pod의 컨테이너에 환경 변수를 설정합니다. 환경 변수는 AWS CLI를 포함한 AWS SDK가 EKS Pod Identity 자격 증명을 사용하도록 구성합니다.

EKS Pod Identity의 이점

EKS Pod Identity는 다음과 같은 이점을 제공합니다.

최소 권한(Least privilege) – IAM 권한의 범위를 서비스 계정으로 한정할 수 있으며, 해당 서비스 계정을 사용하는 Pod만 그 권한에 액세스할 수 있습니다. 이 기능은 또한 kiam이나 kube2iam 같은 타사 솔루션의 필요성을 없앱니다.
자격 증명 격리(Credential isolation) – Amazon EC2 Instance Metadata Service(IMDS)에 대한 액세스가 제한되면, Pod의 컨테이너는 해당 컨테이너가 사용하는 서비스 계정과 연결된 IAM 역할의 자격 증명만 검색할 수 있습니다. 컨테이너는 다른 Pod의 다른 컨테이너가 사용하는 자격 증명에 절대 액세스할 수 없습니다. IMDS가 제한되지 않으면 Pod의 컨테이너는 Amazon EKS 노드 IAM 역할에도 액세스할 수 있으며, 같은 노드의 다른 Pod의 IAM 역할 자격 증명에 접근할 수 있을 수 있습니다. 자세한 내용은 "워커 노드에 할당된 인스턴스 프로파일 액세스 제한"을 참고하세요.

참고: hostNetwork: true로 구성된 Pod는 항상 IMDS 액세스 권한을 갖지만, 활성화되면 AWS SDK와 CLI는 Pod Identity 자격 증명을 사용합니다.

감사 가능성(Auditability) – 사후 감사를 촉진하기 위해 AWS CloudTrail을 통해 액세스 및 이벤트 로깅을 사용할 수 있습니다.

중요: 컨테이너는 보안 경계가 아니며, Pod Identity를 사용한다고 해서 이 사실이 바뀌지 않습니다. 같은 노드에 할당된 Pod는 Pod 구성에 따라 커널과 잠재적으로 다른 리소스를 공유합니다. 별도의 노드에서 실행되는 Pod는 컴퓨팅 계층에서 격리되지만, 개별 인스턴스의 범위를 넘어 Kubernetes API에 추가 권한을 가진 노드 애플리케이션이 있습니다. 예로는 kubelet, kube-proxy, CSI 스토리지 드라이버 또는 자체 Kubernetes 애플리케이션이 있습니다.

EKS Pod Identity는 OIDC ID 공급자를 사용하지 않으므로 서비스 계정용 IAM 역할보다 더 간단한 방법입니다. EKS Pod Identity는 다음과 같은 개선 사항이 있습니다.

독립적인 작업(Independent operations) – 많은 조직에서 OIDC ID 공급자 생성은 Kubernetes 클러스터를 관리하는 팀과 다른 팀의 책임입니다. EKS Pod Identity는 직무를 명확히 분리하여, EKS Pod Identity 연결의 모든 구성은 Amazon EKS에서 수행되고 IAM 권한의 모든 구성은 IAM에서 수행됩니다.
재사용성(Reusability) – EKS Pod Identity는 서비스 계정용 IAM 역할이 클러스터별로 사용하는 별도의 보안 주체 대신 단일 IAM 보안 주체를 사용합니다. IAM 관리자는 다음 보안 주체를 어떤 역할의 신뢰 정책에 추가해 EKS Pod Identity가 사용할 수 있게 만듭니다.

            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            }

확장성(Scalability) – 각 임시 자격 증명 집합은 각 Pod에서 실행되는 각 AWS SDK 대신 EKS Pod Identity의 EKS Auth 서비스가 수임합니다. 그런 다음 각 노드에서 실행되는 Amazon EKS Pod Identity Agent가 SDK에 자격 증명을 발급합니다. 따라서 부하가 노드당 한 번으로 줄어들고 각 Pod에서 중복되지 않습니다. 이 과정의 자세한 내용은 "EKS Pod Identity 작동 방식 이해"를 참고하세요.

두 대안을 비교하는 자세한 내용은 "Kubernetes 서비스 계정으로 워크로드에 AWS 액세스 권한 부여"를 참고하세요.

EKS Pod Identity 설정 개요

다음 절차를 완료하여 EKS Pod Identity를 켜세요.

Amazon EKS Pod Identity Agent 설정 – 이 절차는 각 클러스터에 대해 한 번만 완료합니다. 클러스터에서 EKS Auto Mode가 활성화되어 있다면 이 단계를 완료할 필요가 없습니다.
Kubernetes 서비스 계정에 IAM 역할 할당 – 이 절차는 애플리케이션이 갖기를 원하는 각 고유 권한 집합에 대해 완료합니다.
서비스 계정으로 Pod가 AWS 서비스에 액세스하도록 구성 – AWS 서비스에 액세스해야 하는 각 Pod에 대해 이 절차를 완료합니다.
AWS SDK와 함께 pod identity 사용 – 워크로드가 지원되는 버전의 AWS SDK를 사용하고 기본 자격 증명 체인을 사용하는지 확인합니다.

한계(Limits)

클러스터당 최대 5,000개의 EKS Pod Identity 연결을 지원하여 IAM 역할을 Kubernetes 서비스 계정에 매핑할 수 있습니다.

고려 사항

IAM 역할 연결: 클러스터의 각 Kubernetes 서비스 계정은 클러스터와 동일한 AWS 계정의 IAM 역할 하나와 연결할 수 있습니다. 역할을 변경하려면 EKS Pod Identity 연결을 편집하세요. 크로스 계정 액세스의 경우 IAM 역할을 사용해 역할에 대한 액세스를 위임하세요. 자세한 내용은 IAM 사용 설명서의 "IAM 역할을 사용한 AWS 계정 간 액세스 위임"을 참고하세요.
EKS Pod Identity Agent: Pod Identity Agent는 EKS Pod Identity를 사용하는 데 필요합니다. 에이전트는 클러스터 노드에서 Kubernetes DaemonSet으로 실행되며, 같은 노드의 Pod에만 자격 증명을 제공합니다. 노드의 hostNetwork를 사용하며, 링크-로컬 주소(169.254.170.23(IPv4), [fd00:ec2::23](IPv6))에서 포트 80과 2703을 점유합니다. 클러스터에서 IPv6가 비활성화되어 있다면 EKS Pod Identity Agent의 IPv6를 비활성화하세요. 자세한 내용은 "EKS Pod Identity Agent에서 IPv6 비활성화"를 참고하세요.
최종 일관성(Eventual Consistency): EKS Pod Identity 연결은 최종적으로 일관성을 가지며, API 호출 후 몇 초의 지연이 발생할 수 있습니다. 중요하고 고가용성인 코드 경로에서 연결을 만들거나 업데이트하지 마세요. 대신 덜 빈번하게 실행되는 별도의 초기화 또는 설정 루틴에서 이러한 작업을 수행하세요. 자세한 내용은 EKS 모범 사례 가이드의 "Pod당 보안 그룹"을 참고하세요.
프록시 및 보안 그룹 고려 사항: 프록시를 사용하는 Pod의 경우 no_proxy/NO_PROXY 환경 변수에 169.254.170.23(IPv4)과 [fd00:ec2::23](IPv6)을 추가해 EKS Pod Identity Agent에 대한 요청 실패를 방지하세요. AWS VPC CNI와 함께 Security Groups for Pods를 사용한다면 ENABLE_POD_ENI 플래그를 'true'로, POD_SECURITY_GROUP_ENFORCING_MODE 플래그를 'standard'로 설정하세요. 자세한 내용은 "개별 Pod에 보안 그룹 할당"을 참고하세요.

EKS Pod Identity 클러스터 버전

EKS Pod Identity를 사용하려면 클러스터의 플랫폼 버전이 다음 표에 나열된 버전과 같거나 이후여야 하며, 또는 Kubernetes 버전이 표에 나열된 버전보다 이후여야 합니다. Kubernetes 버전에 맞는 권장 Amazon EKS Pod Identity Agent 버전을 찾으려면 "Amazon EKS 애드온 버전과 클러스터 호환성 확인"을 참고하세요.

Kubernetes 버전	플랫폼 버전
나열되지 않은 Kubernetes 버전	모든 플랫폼 버전 지원
`1.28`	`eks.4`

EKS Pod Identity 제한 사항

EKS Pod Identity는 다음에서 사용할 수 있습니다.

이전 주제 "EKS Pod Identity 클러스터 버전"에 나열된 Amazon EKS 클러스터 버전.
Linux Amazon EC2 인스턴스인 클러스터의 워커 노드.

EKS Pod Identity는 다음에서는 사용할 수 없습니다.

AWS Outposts.
Amazon EKS Anywhere.
Amazon EC2에서 직접 생성하고 실행하는 Kubernetes 클러스터. EKS Pod Identity 구성 요소는 Amazon EKS에서만 사용할 수 있습니다.

EKS Pod Identity는 다음과 함께 사용할 수 없습니다.

Linux Amazon EC2 인스턴스가 아닌 곳에서 실행되는 Pod. AWS Fargate(Fargate)에서 실행되는 Linux 및 Windows Pod는 지원되지 않습니다. Windows Amazon EC2 인스턴스에서 실행되는 Pod는 지원되지 않습니다.

더 알아보기 (Learn more)

공식 문서