서비스 계정용 IAM 역할
서비스 계정용 IAM 역할 (IAM Roles for Service Accounts, IRSA)
Kubernetes 서비스 계정에 IAM 역할을 연결해 Pod에 AWS 액세스 권한을 부여하는 메커니즘인 IRSA(서비스 계정용 IAM 역할)를 설명합니다.
출처: 문서
본문
팁: 예정된 Amazon EKS 워크숍에 등록하세요.
Pod의 컨테이너에 있는 애플리케이션은 AWS SDK나 AWS CLI를 사용해 AWS Identity and Access Management(IAM) 권한으로 AWS 서비스에 API 요청을 할 수 있습니다. 애플리케이션은 AWS API 요청에 AWS 자격 증명으로 서명해야 합니다. 서비스 계정용 IAM 역할(IRSA)은 Amazon EC2 인스턴스 프로파일이 Amazon EC2 인스턴스에 자격 증명을 제공하는 방식과 유사하게, 애플리케이션의 자격 증명을 관리하는 기능을 제공합니다. AWS 자격 증명을 생성해 컨테이너에 배포하거나 Amazon EC2 인스턴스의 역할을 사용하는 대신, IAM 역할을 Kubernetes 서비스 계정과 연결하고 Pod를 해당 서비스 계정을 사용하도록 구성합니다. AWS Outposts의 Amazon EKS 로컬 클러스터에서는 서비스 계정용 IAM 역할을 사용할 수 없습니다.
서비스 계정용 IAM 역할은 다음과 같은 이점을 제공합니다.
- 최소 권한(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는 IRSA 자격 증명을 사용합니다.
- 감사 가능성(Auditability) – 사후 감사를 보장하기 위해 AWS CloudTrail을 통해 액세스 및 이벤트 로깅을 사용할 수 있습니다.
중요: 컨테이너는 보안 경계가 아니며, 서비스 계정용 IAM 역할을 사용한다고 해서 이 사실이 바뀌지 않습니다. 같은 노드에 할당된 Pod는 Pod 구성에 따라 커널과 잠재적으로 다른 리소스를 공유합니다. 별도의 노드에서 실행되는 Pod는 컴퓨팅 계층에서 격리되지만, 개별 인스턴스의 범위를 넘어 Kubernetes API에 추가 권한을 가진 노드 애플리케이션이 있습니다. 예로는
kubelet,kube-proxy, CSI 스토리지 드라이버 또는 자체 Kubernetes 애플리케이션이 있습니다.
다음 절차를 완료하여 서비스 계정용 IAM 역할을 활성화하세요.
- 클러스터용 IAM OIDC 공급자 생성 – 이 절차는 각 클러스터에 대해 한 번만 완료합니다.
참고: 클러스터의 VPC에 아웃바운드 인터넷 액세스가 없고 클러스터 OIDC 엔드포인트에 대한 프라이빗 액세스를 설정하지 않았다면,
eksctl로 OIDC 공급자를 생성하는 것처럼 VPC 내부에서 해당 엔드포인트에 도달하는 작업은 OIDC 발급자 호스트 이름을 확인할 수 없습니다. 예제 오류 메시지는 다음과 같습니다.
server cant find oidc.eks.region.amazonaws.com: NXDOMAIN
VPC에서 클러스터 OIDC 엔드포인트에 프라이빗으로 도달하려면, 프라이빗 DNS를 활성화한 상태에서 이에 대한 VPC 인터페이스 엔드포인트(com.amazonaws.region-code.oidc-eks)를 생성하세요. 자세한 내용은 "AWS PrivateLink를 사용한 Amazon EKS 액세스"를 참고하세요. 또는 VPC 외부(예: AWS CloudShell)에서 명령을 실행하거나 split-horizon 조건부 리졸버를 만들 수도 있습니다. 예제는 GitHub의 Amazon EKS 기능 요청을 참고하세요.
- Kubernetes 서비스 계정에 IAM 역할 할당 – 이 절차는 애플리케이션이 갖기를 원하는 각 고유 권한 집합에 대해 완료합니다.
- Pod가 Kubernetes 서비스 계정을 사용하도록 구성 – AWS 서비스에 액세스해야 하는 각 Pod에 대해 이 절차를 완료합니다.
- AWS SDK와 함께 IRSA 사용 – 워크로드가 지원되는 버전의 AWS SDK를 사용하고 기본 자격 증명 체인을 사용하는지 확인합니다.
IAM, Kubernetes 및 OpenID Connect(OIDC) 배경 정보
2014년 AWS Identity and Access Management는 OpenID Connect(OIDC)를 사용하는 페더레이션 ID 지원을 추가했습니다. 이 기능을 사용하면 지원되는 ID 공급자로 AWS API 호출을 인증하고 유효한 OIDC JSON 웹 토큰(JWT)을 받을 수 있습니다. 이 토큰을 AWS STS AssumeRoleWithWebIdentity API 작업에 전달해 IAM 임시 역할 자격 증명을 받을 수 있습니다. 이 자격 증명을 사용해 Amazon S3와 DynamoDB를 포함한 모든 AWS 서비스와 상호작용할 수 있습니다.
각 JWT 토큰은 서명 키 쌍으로 서명됩니다. 키는 Amazon EKS가 관리하는 OIDC 공급자에서 제공되며 프라이빗 키는 7일마다 교체됩니다. Amazon EKS는 공개 키를 만료될 때까지 보관합니다. 외부 OIDC 클라이언트를 연결하는 경우, 공개 키가 만료되기 전에 서명 키를 새로고침해야 합니다. OIDC 토큰을 검증하기 위해 서명 키를 가져오는 방법을 알아보세요.
Kubernetes는 오랫동안 자체 내부 ID 시스템으로 서비스 계정을 사용해 왔습니다. Pod는 Kubernetes API 서버만 검증할 수 있는 자동 마운트 토큰(비-OIDC JWT)으로 Kubernetes API 서버에 인증할 수 있습니다. 이러한 레거시 서비스 계정 토큰은 만료되지 않으며, 서명 키 교체는 어려운 과정입니다. Kubernetes 버전 1.12에서 새 ProjectedServiceAccountToken 기능에 대한 지원이 추가되었습니다. 이 기능은 서비스 계정 ID도 포함하고 구성 가능한 오디언스를 지원하는 OIDC JSON 웹 토큰입니다.
Amazon EKS는 각 클러스터에 대해 ProjectedServiceAccountToken JSON 웹 토큰의 서명 키가 포함된 공개 OIDC 검색 엔드포인트를 호스팅하므로, IAM 같은 외부 시스템이 Kubernetes가 발급한 OIDC 토큰을 검증하고 수락할 수 있습니다.