IRSA로 다른 계정에 인증

IRSA로 다른 계정에 인증

다른 AWS 계정의 클러스터에서 ID 공급자를 만들거나 연결된 AssumeRole 작업을 사용해 크로스 계정 IAM 권한을 구성하는 방법을 설명합니다.

출처: 문서

본문

다른 계정의 클러스터에서 ID 공급자를 만들거나 연결된(chained) AssumeRole 작업을 사용해 크로스 계정 IAM 권한을 구성할 수 있습니다. 다음 예제에서 계정 A는 서비스 계정용 IAM 역할을 지원하는 Amazon EKS 클러스터를 소유합니다. 해당 클러스터에서 실행되는 Pod는 계정 B의 IAM 권한을 수임해야 합니다.

• 옵션 1은 더 간단하지만 계정 B가 계정 A 클러스터용 OIDC ID 공급자를 생성하고 관리해야 합니다.
• 옵션 2는 OIDC 관리를 계정 A에 유지하지만 두 번의 AssumeRole 호출을 통한 역할 연결이 필요합니다.

옵션 1: 다른 계정의 클러스터에서 ID 공급자 생성

이 예제에서 계정 A는 클러스터의 OpenID Connect(OIDC) 발급자 URL을 계정 B에 제공합니다. 계정 B는 계정 A 클러스터의 OIDC 발급자 URL을 사용해 "클러스터용 IAM OIDC 공급자 생성"과 "Kubernetes 서비스 계정에 IAM 역할 할당"의 지침을 따릅니다. 그런 다음 클러스터 관리자는 계정 A 클러스터의 서비스 계정에 계정 B(444455556666)의 역할을 사용하도록 주석을 답니다.

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::444455556666:role/account-b-role

옵션 2: 연결된 AssumeRole 작업 사용

이 접근 방식에서는 각 계정이 IAM 역할을 생성합니다. 계정 B의 역할은 계정 A를 신뢰하고, 계정 A의 역할은 OIDC 페더레이션을 사용해 클러스터에서 자격 증명을 가져옵니다. 그러면 Pod가 AWS CLI 프로파일을 사용해 두 역할을 연결합니다.

1단계: 계정 B에서 대상 역할 생성

계정 B(444455556666)는 계정 A 클러스터의 Pod에 필요한 권한을 가진 IAM 역할을 생성합니다. 계정 B는 원하는 권한 정책을 이 역할에 연결한 다음 다음 신뢰 정책을 추가합니다.

계정 B 역할의 신뢰 정책 – 이 정책은 계정 A의 특정 IRSA 역할이 이 역할을 수임하도록 허용합니다.

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

중요: 최소 권한을 위해 계정 루트(arn:aws:iam::111122223333:root)를 사용하는 대신 Principal ARN을 계정 A의 특정 역할 ARN으로 바꾸세요. 계정 루트를 사용하면 계정 A의 모든 IAM 보안 주체가 이 역할을 수임할 수 있습니다.

2단계: 계정 A에서 IRSA 역할 생성

계정 A(111122223333)는 클러스터의 OIDC 발급자 주소로 생성된 ID 공급자에서 자격 증명을 가져오는 신뢰 정책을 가진 역할을 생성합니다.

계정 A 역할의 신뢰 정책(OIDC 페더레이션) – 이 정책은 EKS 클러스터의 OIDC 공급자가 이 역할에 대한 자격 증명을 발급하도록 허용합니다.

{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

중요: 최소 권한을 위해, 이 역할을 특정 Kubernetes 서비스 계정으로 제한하도록 sub 클레임에 대한 StringEquals 조건을 추가하세요. sub 조건이 없으면 클러스터의 모든 서비스 계정이 이 역할을 수임할 수 있습니다. sub 값은 system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME 형식을 사용합니다. 예를 들어 default 네임스페이스의 my-service-account라는 서비스 계정으로 제한하려면:

"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"

3단계: 계정 A의 역할에 AssumeRole 권한 연결

계정 A는 2단계에서 생성한 역할에 권한 정책을 연결합니다. 이 정책은 역할이 계정 B의 역할을 수임하도록 허용합니다.

계정 A 역할의 권한 정책 – 이 정책은 계정 B의 대상 역할에 대한 sts:AssumeRole을 부여합니다.

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

4단계: Pod가 역할을 연결하도록 구성

Pod가 계정 B의 역할을 수임하기 위한 애플리케이션 코드는 두 프로파일(account_b_role과 account_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::444455556666: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::111122223333:role/account-a-role

다른 AWS SDK에 연결된 프로파일을 지정하려면 사용 중인 SDK의 문서를 참고하세요. 자세한 내용은 "Tools to Build on AWS"를 참고하세요.

더 알아보기 (Learn more)

• 공식 문서