IRSA를 사용하여 다른 계정에 인증

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

옵션 1: 다른 계정의 클러스터에서 ID 제공업체 생성

이 예제에서 계정 A는 계정 B에 클러스터의 OpenID Connect(OIDC) 발행자 URL을 제공합니다. 계정 B는 계정 A의 클러스터에서 OIDC 발급자 URL을 사용하여 클러스터에 대한 IAM OIDC 제공자 만들기 및 Kubernetes 서비스 계정에 IAM 역할 할당의 지침을 따릅니다. 그런 다음 클러스터 관리자는 계정 B(444455556666)의 역할을 사용할 계정 A의 클러스터에 있는 서비스 계정에 주석을 답니다.

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 페더레이션을 사용하여 클러스터에서 자격 증명을 가져옵니다. 그런 다음 포드는 AWS CLI 프로파일을 사용하여 두 역할을 함께 연결합니다.

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

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

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

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

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"
        }
      }
    }
  ]
}

"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단계: 역할을 연결하도록 포드 구성

포드가 계정 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에 대한 설명서를 참조하세요. 자세한 내용은 AWS 기반의 도구를 참조하세요.