서비스 계정의 IAM 역할에 대한 기술 개요 - Amazon EKS

문서의 영문과 번역 사이에 충돌이 있는 경우에는 영문 버전을 따릅니다. 번역 버전은 기계 번역을 사용하여 제공합니다.

서비스 계정의 IAM 역할에 대한 기술 개요

2014년 AWS Identity and Access Management에서는 OpenID Connect(OIDC)를 사용해 연동 자격 증명을 지원하는 기능을 추가하였습니다. 이 기능을 사용하면 지원되는 자격 증명 공급자를 이용해 AWS API 호출을 인증하고 유효한 OIDC JSON 웹 토큰(JWT)을 수신할 수 있습니다. 이 토큰을 AWS STS AssumeRoleWithWebIdentity API 작업에 전달하고 IAM 임시 역할 자격 증명을 수신할 수 있습니다. 이 자격 증명을 사용하여 Amazon S3, DynamoDB과 같은 AWS 서비스와 상호 작용할 수 있습니다.

Kubernetes는 서비스 계정을 자체 내부 자격 증명 시스템으로 오랫동안 사용해 왔습니다. 포드는 Kubernetes API 서버에서만 검증할 수 있는 자동으로 마운트되는 토큰(OIDC JWT는 아니었음)을 사용하는 Kubernetes API 서버를 통해 인증을 할 수 있습니다. 이러한 레거시 서비스 계정 토큰은 만료되지 않으며, 서명 키를 교체하려면 까다로운 프로세스를 거쳐야 합니다. Kubernetes 버전 1.12에서는 새로운 ProjectedServiceAccountToken 기능에 대한 지원을 추가하였습니다. 이 기능은 서비스 계정 자격 증명도 포함된 OIDC JSON 웹 토큰이며 구성 가능한 대상을 지원합니다.

이제 Amazon EKS에서는 ProjectedServiceAccountToken JSON 웹 토큰에 대한 서명 키가 포함된 클러스터 1개당 공개 OIDC 검색 엔드포인트 1개를 호스팅합니다. 따라서 IAM과 같은 외부 시스템에서는 Kubernetes가 발행한 OIDC 토큰을 검증하고 수락할 수 있습니다.

IAM 역할 구성

IAM에서 클러스터의 OIDC 제공자, 서비스 계정 네임스페이스, 선택 사항인 서비스 계정 이름으로 범위가 지정된 신뢰 관계를 사용해 IAM 역할을 생성한 다음 서비스 계정에 연결하려는 IAM 정책을 연결합니다. 아래의 StringEqualsStringLike 조건에서 여러 항목을 추가하여 해당 역할이 포함된 여러 개의 서비스 계정 또는 네임스페이스를 사용할 수 있습니다.

  • 역할의 범위를 특정 서비스 계정에 한정하려면 다음과 같이 하십시오.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/OIDC_PROVIDER" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "OIDC_PROVIDER:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:SERVICE_ACCOUNT_NAME" } } } ] }
  • 역할의 범위를 전체 네임스페이스로 지정하려면(네임스페이스를 경계로 사용하려면) 다음과 같이 하십시오.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/OIDC_PROVIDER" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringLike": { "OIDC_PROVIDER:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:*" } } } ] }

서비스 계정 구성

Kubernetes에서 eks.amazonaws.com/role-arn 주석을 서비스 계정에 추가하여 클러스터에서 서비스 계정에 연결할 IAM 역할을 정의합니다.

apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME

포드 구성

클러스터의 Amazon EKS 포드 자격 증명 Webhook은 이 주석을 이용해 서비스 계정에 연결된 포드를 관찰하고 다음 환경 변수를 적용합니다.

AWS_ROLE_ARN=arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
참고

클러스터에서는 환경 변수 및 토큰 파일 마운트를 구성하기 위해 변형 웹 후크를 사용할 필요가 없습니다. 그 대신 이러한 환경 변수를 수동으로 추가하도록 포드를 구성할 수 있습니다.

지원되는 AWS SDK 버전은 자격 증명 체인 제공자에서 이 환경 변수를 먼저 찾습니다. 역할 자격 증명은 이 기준을 충족하는 포드에 사용됩니다.

참고

포드가 서비스 계정과 연결된 IAM 역할의 AWS 자격 증명을 사용하는 경우 이 포드의 컨테이너에 있는 AWS CLI 또는 기타 SDK에서는 이 역할이 배타적으로 제공하는 자격 증명을 사용합니다. 더 이상 상속되지 않습니다. IAM 노드의 사용 권한 IAM 역할.

기본적으로 root로 실행되는 컨테이너에만 웹 ID 토큰 파일을 읽을 수 있는 적절한 파일 시스템 권한이 있습니다. 컨테이너를 root로 실행하거나 매니페스트의 컨테이너에 대해 다음 보안 컨텍스트를 제공하여 이러한 권한을 제공할 수 있습니다. fsGroup ID는 임의적이며 유효한 그룹 ID를 선택할 수 있습니다. 포드의 보안 컨텍스트 설정이 미치는 영향에 대한 자세한 내용은 Kubernetes 설명서의 Configure a Security Context for a Pod or Container를 참조하십시오.

apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: template: metadata: labels: app: my-app spec: serviceAccountName: my-app containers: - name: my-app image: my-app:latest securityContext: fsGroup: 1337 ...

kubelet 는 그룹을 대신하여 토큰을 요청하고 저장합니다. 기본적으로 kubelet 총 TTL의 80%보다 오래되었거나 토큰이 24시간보다 오래된 경우 토큰을 새로 고칩니다. 기본 서비스 계정을 제외한 모든 계정의 만료 기간은 포드 사양의 설정으로 수정할 수 있습니다. 자세한 내용은 을 참조하십시오. 서비스 계정 토큰 볼륨 예상 를 참조하십시오.

교차 계정 IAM 권한

다른 계정의 클러스터에서 자격 증명 공급자를 생성하거나 연결된 AssumeRole 작업을 사용하여 교차 계정 IAM 권한을 구성할 수 있습니다. 다음 예에서 계정 A는 서비스 계정에 대해 IAM 역할을 지원하는 Amazon EKS 클러스터를 소유합니다. 이 클러스터에서 실행되는 포드는 계정 B의 IAM 권한을 가정해야 합니다.

예: 다른 계정의 클러스터에서 자격 증명 공급자 생성

이 예에서 계정 A는 계정 B에 클러스터의 OIDC 발행자 URL을 제공합니다. 계정 B는 계정 A의 클러스터에서 OIDC 발행자 URL을 사용하여 클러스터에서 서비스 계정의 IAM 역할 활성화서비스 계정을 위한 IAM 역할 및 정책 생성의 지침을 따릅니다. 그런 다음 클러스터 관리자는 계정 B의 역할을 사용할 계정 A의 클러스터에 있는 서비스 계정에 주석을 답니다.

apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_B_AWS_ACCOUNT_ID:role/IAM_ROLE_NAME

예: 연결된 AssumeRole 작업 사용

이 예에서 계정 B는 계정 A의 클러스터에 있는 포드에 부여할 권한이 포함된 IAM 정책을 생성합니다. 계정 B는 아래와 같이 계정 A에 AssumeRole 권한을 허용하는 신뢰 관계(111111111111)를 이용해 이 정책을 IAM 역할에 연결합니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] }

계정 A는 아래와 같이 클러스터의 OIDC 발행자 URL로 생성된 자격 증명 공급자의 자격 증명을 가져오는 신뢰 정책을 이용해 역할을 생성합니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111111111111:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLEC061A78C479E31025A21AC4CDE191335D05820BE5CE" }, "Action": "sts:AssumeRoleWithWebIdentity" } ] }

계정 A는 이 역할을 계정 B가 생성한 역할을 맡을 수 있는 다음과 같은 권한이 포함된 정책에 연결합니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::222222222222:role/account-b-role" } ] }

계정 B의 역할을 맡을 포드의 애플리케이션 코드는 두 가지 프로필을 사용합니다. account_b_roleaccount_a_role. 더 account_b_role 프로필은 account_a_role 프로필이 소스로 사용됩니다. AWS CLI의 경우 ~/.aws/config 파일은 다음 예시와 같습니다.

[profile account_b_role] source_profile = account_a_role role_arn=arn:aws:iam::222222222222:role/account-b-role [profile account_a_role] web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token role_arn=arn:aws:iam::111111111111:role/account-a-role

연결된 프로필을 다른 AWS SDK에 지정하려면 해당 문서를 참조하십시오.