역할을 사용해 크로스 계정 AWS 액세스 위임하기

역할을 사용해 크로스 계정 AWS 액세스 위임하기 (튜토리얼)

중요 – IAM 모범 사례에서는 휴먼 사용자가 장기 자격 증명을 가진 IAM 사용자를 사용하는 대신, 자격 증명 공급자와의 페더레이션으로 임시 자격 증명을 사용해 AWS에 접근할 것을 권장해요. 페더레이션 사용자가 지원하지 않는 특정 사용 사례에만 IAM 사용자를 사용하는 것을 권장해요.

이 튜토리얼에서는 Destination(대상)과 Originating(발신)이라 부르는 서로 다른 AWS 계정의 리소스에 대한 접근을 위임하기 위해 역할을 사용하는 방법을 배워요. 한 계정의 리소스를 다른 계정의 사용자와 공유하게 돼요. 이렇게 크로스 계정 접근을 설정하면 각 계정마다 개별 IAM 사용자를 만들 필요가 없어요. 또한 사용자가 다른 AWS 계정의 리소스에 접근하기 위해 한 계정에서 로그아웃하고 다른 계정에 로그인할 필요도 없어요. 역할을 구성한 뒤에는 AWS Management Console, AWS CLI, API에서 해당 역할을 사용하는 방법을 살펴볼 거예요.

출처: 문서

본문

이 튜토리얼에서 Destination 계정은 여러 애플리케이션과 팀이 접근하는 애플리케이션 데이터를 관리해요. 각 계정에서 애플리케이션 정보를 Amazon S3 버킷에 저장해요. Originating 계정에는 IAM 사용자 역할 두 개인 Developers와 Analysts를 관리해요. Developers와 Analysts는 여러 마이크로서비스가 공유하는 데이터를 생성하기 위해 Originating 계정을 사용해요. 두 역할 모두 Originating 계정에서 작업하고 해당 계정의 리소스에 접근할 권한이 있어요. 때때로 개발자는 Destination 계정의 공유 데이터를 업데이트해야 해요. 개발자들은 이 데이터를 amzn-s3-demo-bucket-shared-container라는 Amazon S3 버킷에 저장해요.

이 튜토리얼이 끝나면 다음이 갖춰져요:

• Destination 계정의 특정 역할을 맡도록 허용된 Originating 계정(신뢰받는 계정)의 사용자
• 특정 Amazon S3 버킷에 접근하도록 허용된 Destination 계정(신뢰하는 계정)의 역할
• Destination 계정의 amzn-s3-demo-bucket-shared-container 버킷
• 개발자는 AWS Management Console에서 역할을 사용해 Destination 계정의 amzn-s3-demo-bucket-shared-container 버킷에 접근할 수 있어요. 또한 역할이 제공하는 임시 자격 증명으로 인증된 API 호출로 버킷에 접근할 수도 있어요. Analyst가 같은 역할을 사용하려는 시도는 실패해요.

이 워크플로는 세 가지 기본 단계로 이루어져 있어요.

Destination 계정에 역할 생성

먼저 AWS Management Console로 Destination 계정(계정 ID 999999999999)과 Originating 계정(계정 ID 111111111111) 간의 신뢰를 설정해요. UpdateData라는 IAM 역할을 만드는 것으로 시작해요. 역할을 만들 때 Originating 계정을 신뢰할 엔터티로 정의하고, 신뢰받는 사용자가 amzn-s3-demo-bucket-shared-container 버킷을 업데이트할 수 있게 하는 권한 정책을 지정해요.

역할에 대한 접근 권한 부여

이 섹션에서는 Analyst가 UpdateData 역할에 접근하지 못하도록 역할 정책을 수정해요. 이 시나리오에서 Analyst는 PowerUser 접근 권한을 갖고 있기 때문에 역할 사용을 명시적으로 거부(deny)해야 해요.

역할 전환으로 접근 테스트

마지막으로 Developer 자격으로 UpdateData 역할을 사용해 Destination 계정의 amzn-s3-demo-bucket-shared-container 버킷을 업데이트해요. AWS 콘솔, AWS CLI, API를 통해 역할에 접근하는 방법을 보게 될 거예요.

고려 사항 (Considerations)

IAM 역할을 사용해 AWS 계정 간 리소스 접근을 위임하기 전에 다음 사항을 고려하는 것이 중요해요.

• AWS 계정 루트 사용자로 로그인하면 역할로 전환할 수 없어요.
• IAM 역할과 리소스 기반 정책은 단일 파티션 내에서만 계정 간 접근을 위임해요. 예를 들어 표준 aws 파티션의 미국 서부(북캘리포니아)에 계정이 있고, aws-cn 파티션의 중국(베이징)에도 계정이 있다고 가정해 볼게요. 중국(베이징) 계정의 Amazon S3 리소스 기반 정책으로 표준 aws 계정의 사용자에 대한 접근을 허용할 수는 없어요.
• AWS IAM Identity Center를 사용해 SAML(Security Assertion Markup Language)로 외부 AWS 계정(AWS Organizations 외부의 계정)에 대한 SSO(단일 로그온)를 지원할 수 있어요. 자세한 내용은 AWS IAM Identity Center로 외부 AWS 계정을 통합해 독립 청구와 함께 SAML 2.0으로 중앙 접근 관리를 참고하세요.
• 역할을 Amazon EC2 인스턴스나 AWS Lambda 함수 같은 AWS 리소스에 연결할 수 있어요. 자세한 내용은 AWS 서비스에 권한을 위임할 역할 생성을 참고하세요.
• 애플리케이션이 다른 AWS 계정의 역할을 맡게 하려면 AWS SDK의 크로스 계정 역할 전환을 사용할 수 있어요. 자세한 내용은 _AWS SDKs and Tools Reference Guide_의 인증 및 접근을 참고하세요.
• AWS Management Console로 역할을 전환하는 것은 ExternalId를 요구하지 않는 계정에서만 동작해요. 예를 들어 제3자에게 계정 접근 권한을 부여하면서 권한 정책의 Condition 요소에 ExternalId를 요구한다고 가정해 볼게요. 이 경우 제3자는 AWS API나 명령줄 도구로만 계정에 접근할 수 있어요. 콘솔은 ExternalId 값을 제공해야 하기 때문에 제3자는 콘솔을 사용할 수 없어요. 이 시나리오에 대한 자세한 내용은 "제3자가 소유한 AWS 계정 접근"과 AWS Security Blog의 "How to enable cross account access to the AWS Management Console"을 참고하세요.

사전 요구 사항 (Prerequisites)

이 튜토리얼은 다음이 이미 준비되어 있다고 가정해요.

• Originating 계정과 Destination 계정을 각각 나타낼 두 개의 별도 AWS 계정
• Originating 계정에 다음처럼 생성·구성된 사용자와 역할

직함	사용자	권한
Developer	David	두 사용자 모두 Originating 계정에서 AWS Management Console에 로그인해 사용할 수 있어요.
Analyst	Jane

• Destination 계정에는 어떤 사용자도 만들 필요가 없어요.
• Destination 계정에 생성된 Amazon S3 버킷. 이 튜토리얼에서는 amzn-s3-demo-bucket-shared-container라 부르지만, S3 버킷 이름은 전 세계적으로 고유해야 하므로 다른 이름의 버킷을 사용해야 해요.

Destination 계정에 역할 생성 (Create a role in the Destination Account)

한 AWS 계정의 사용자가 다른 AWS 계정의 리소스에 접근하도록 허용할 수 있어요. 이 튜토리얼에서는 접근할 수 있는 사람과 전환한 사용자에게 부여되는 권한을 정의하는 역할을 만들어 이 작업을 해요.

이 단계에서는 Destination 계정에 역할을 만들고 Originating 계정을 신뢰할 엔터티로 지정해요. 또한 역할 권한을 amzn-s3-demo-bucket-shared-container 버킷에 대한 읽기와 쓰기 접근으로만 제한해요. 역할 사용 권한을 부여받은 사람은 누구나 shared-container 버킷에 읽고 쓸 수 있어요.

역할을 만들기 전에 Originating AWS 계정의 _계정 ID_가 필요해요. 각 AWS 계정에는 고유한 계정 ID 식별자가 할당돼 있어요.

Originating AWS 계정 ID 얻기

1. Originating 계정의 관리자로 AWS Management Console에 로그인하고 https://console.aws.amazon.com/iam/ 에서 IAM 콘솔을 열어요.
2. IAM 콘솔에서 오른쪽 위 탐색 모음의 사용자 이름을 선택해요. 일반적으로 username@account_ID_number_or_alias처럼 보여요.
3. 이 시나리오에서는 Originating 계정에 계정 ID 111111111111을 사용할 수 있어요. 하지만 테스트 환경에서 이 시나리오를 사용한다면 유효한 계정 ID를 사용해야 해요.

Originating 계정이 사용할 수 있는 Destination 계정의 역할 생성

1. Destination 계정의 관리자로 AWS Management Console에 로그인하고 IAM 콘솔을 열어요.
2. 역할을 만들기 전에 역할 요구 사항의 권한을 정의하는 관리형 정책을 준비해요. 이 정책을 이후 단계에서 역할에 연결해요.
3. amzn-s3-demo-bucket-shared-container 버킷에 대한 읽기·쓰기 접근을 설정하려고 해요. AWS는 일부 Amazon S3 관리형 정책을 제공하지만, 단일 Amazon S3 버킷에 대한 읽기·쓰기 접근을 제공하는 정책은 없어요. 대신 직접 정책을 만들 수 있어요.
4. 탐색 창에서 Policies를 선택한 뒤 Create policy를 선택해요.
5. JSON 탭을 선택하고 다음 JSON 정책 문서에서 텍스트를 복사해요. 이 텍스트를 JSON 텍스트 상자에 붙여넣되, 리소스 ARN(arn:aws:s3:::shared-container)을 실제 Amazon S3 버킷의 ARN으로 바꿔요.

{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
       ],
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container/*"
    }
  ]
}

ListAllMyBuckets 액션은 요청의 인증된 발신자가 소유한 모든 버킷을 나열할 권한을 부여해요. ListBucket 권한은 사용자가 amzn-s3-demo-bucket-shared-container 버킷의 객체를 볼 수 있게 해요. GetObject, PutObject, DeleteObject 권한은 사용자가 amzn-s3-demo-bucket-shared-container 버킷의 내용을 보고, 업데이트하고, 삭제할 수 있게 해요.

참고 – Visual과 JSON 편집기 옵션을 언제든 전환할 수 있어요. 하지만 Visual 편집기에서 변경하거나 Next를 선택하면 IAM이 비주얼 편집기에 맞게 정책을 재구성할 수 있어요. 자세한 내용은 "정책 재구성"을 참고하세요.

6. Review and create 페이지에서 정책 이름에 read-write-app-bucket을 입력해요. 정책이 부여하는 권한을 검토한 뒤 Create policy를 선택해 작업을 저장해요.
7. 새 정책이 관리형 정책 목록에 나타나요.
8. 탐색 창에서 Roles를 선택한 뒤 Create role을 선택해요.
9. An AWS account 역할 유형을 선택해요.
10. Account ID에 Originating 계정 ID를 입력해요. 이 튜토리얼에서는 Originating 계정에 예시 계정 ID 111111111111을 사용해요. 유효한 계정 ID를 사용해야 해요. 111111111111 같은 유효하지 않은 계정 ID를 사용하면 IAM이 새 역할을 만들 수 없게 해요.
11. 지금은 외부 ID를 요구하거나 역할을 맡기 위해 MFA(다중 인증)를 요구할 필요가 없어요. 이 옵션은 선택하지 않은 채로 두세요. 자세한 내용은 "IAM의 AWS 다중 인증"을 참고하세요.
12. 역할과 연결할 권한을 설정하려면 Next: Permissions를 선택해요.
13. 이전에 만든 정책 옆의 확인란을 선택해요.
14. 팁 – Filter에서 Customer managed를 선택해 직접 만든 정책만 목록에 표시되게 해요. 이렇게 하면 AWS가 만든 정책이 숨겨져 필요한 정책을 훨씬 쉽게 찾을 수 있어요.
15. 그런 다음 Next를 선택해요.
16. (선택 사항) 태그를 키-값 쌍으로 연결해 역할에 메타데이터를 추가해요. IAM에서 태그 사용에 대한 자세한 내용은 "AWS Identity and Access Management 리소스 태그"를 참고하세요.
17. (선택 사항) Description에 새 역할에 대한 설명을 입력해요.
18. 역할을 검토한 뒤 Create role을 선택해요.
19. UpdateData 역할이 역할 목록에 나타나요.

이제 역할의 ARN(Amazon Resource Name), 즉 역할의 고유 식별자를 구해야 해요. Originating 계정에서 Developer의 역할을 수정할 때 권한을 부여하거나 거부하려면 Destination 계정의 역할 ARN을 지정해요.

UpdateData의 ARN 얻기

1. IAM 콘솔의 탐색 창에서 Roles를 선택해요.
2. 역할 목록에서 UpdateData 역할을 선택해요.
3. 세부 정보 창의 Summary 섹션에서 Role ARN 값을 복사해요.

Destination 계정의 계정 ID가 999999999999이므로 역할 ARN은 arn:aws:iam::999999999999:role/UpdateData예요. Destination 계정의 실제 AWS 계정 ID를 제공해야 해요.

이 시점에서 Destination 계정의 역할이 Originating 계정을 신뢰할 프린시펄로 식별하면서 두 계정 간의 신뢰가 설정됐어요. 또한 UpdateData 역할로 전환하는 사용자가 무엇을 할 수 있는지도 정의했어요.

다음으로 Developer 역할의 권한을 수정해요.

역할에 대한 접근 권한 부여 (Grant access to the role)

이 시점에서 Analyst와 Developer 모두 Originating 계정의 데이터를 관리할 수 있는 권한을 갖고 있어요. 역할로 전환할 수 있게 권한을 추가하는 필수 단계를 사용해요.

Developers 역할이 UpdateData 역할로 전환할 수 있게 수정

1. Originating 계정의 관리자로 로그인하고 IAM 콘솔을 열어요.
2. Roles를 선택한 뒤 Developers를 선택해요.
3. Permissions 탭을 선택하고 Add permissions를 선택한 뒤 Create inline policy를 선택해요.
4. JSON 탭을 선택해요.
5. Destination 계정의 UpdateData 역할에 대한 AssumeRole 액션을 허용하도록 다음 정책 문을 추가해요. Resource 요소의 DESTINATION-ACCOUNT-ID를 Destination 계정의 실제 AWS 계정 ID로 반드시 바꿔요.

{
    "Version":"2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::111122223333:role/UpdateData"
    }
}

Allow 효과는 Developers 그룹이 Destination 계정의 UpdateData 역할에 접근할 수 있게 명시적으로 허용해요. 역할에 접근하려는 모든 개발자는 성공해요.

6. Review policy를 선택해요.
7. allow-assume-S3-role-in-destination 같은 이름(Name) 을 입력해요.
8. Create policy를 선택해요.

대부분의 환경에서는 다음 절차가 필요하지 않을 수 있어요. 하지만 PowerUserAccess 권한을 사용한다면 일부 그룹이 이미 역할을 전환할 수 있을 거예요. 다음 절차는 Analyst 그룹이 역할을 맡을 수 없도록 "Deny" 권한을 추가하는 방법을 보여줘요. 환경에서 이 절차가 필요하지 않다면 추가하지 않는 것을 권장해요. "Deny" 권한은 전체 권한 그림을 관리하고 이해하기 더 복잡하게 만들어요. 더 나은 옵션이 없을 때만 "Deny" 권한을 사용하세요.

Analysts 역할이 UpdateData 역할을 맡는 것을 거부하도록 수정

1. Roles를 선택한 뒤 Analysts를 선택해요.
2. Permissions 탭을 선택하고 Add permissions를 선택한 뒤 Create inline policy를 선택해요.
3. JSON 탭을 선택해요.
4. UpdateData 역할에 대한 AssumeRole 액션을 거부하도록 다음 정책 문을 추가해요. Resource 요소의 DESTINATION-ACCOUNT-ID를 Destination 계정의 실제 AWS 계정 ID로 반드시 바꿔요.

{
    "Version":"2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::111122223333:role/UpdateData"
    }
}

Deny 효과는 Analyst 그룹이 Destination 계정의 UpdateData 역할에 접근하는 것을 명시적으로 거부해요. 역할에 접근하려는 모든 analyst는 접근 거부 메시지를 받아요.

5. Review policy를 선택해요.
6. deny-assume-S3-role-in-destination 같은 이름(Name) 을 입력해요.
7. Create policy를 선택해요.

이제 Developers 역할은 Destination 계정의 UpdateData 역할을 사용할 권한을 갖고, Analysts 역할은 UpdateData 역할을 사용하지 못하게 돼요.

다음으로 개발자 David가 Destination 계정의 amzn-s3-demo-bucket-shared-container 버킷에 어떻게 접근하는지 볼 수 있어요. David는 AWS Management Console, AWS CLI, AWS API에서 버킷에 접근할 수 있어요.

역할 전환으로 접근 테스트 (Test access by switching roles)

이 튜토리얼의 처음 두 단계를 완료하면 Destination 계정의 리소스에 접근 권한을 부여하는 역할이 생겨요. 또한 그 역할을 사용하도록 허용된 사용자를 가진 Originating 계정의 역할도 하나 있어요. 이 단계에서는 AWS Management Console, AWS CLI, AWS API에서 그 역할로 전환하는 방법을 테스트하는 방법을 다뤄요.

IAM 역할 작업 중 겪을 수 있는 일반적인 문제에 대한 도움은 "IAM 역할 문제 해결"을 참고하세요.

역할 전환 (콘솔)

David가 AWS Management Console에서 Destination 계정의 데이터를 업데이트해야 한다면 Switch Role을 사용해 그렇게 할 수 있어요. 계정 ID 또는 별칭과 역할 이름을 지정하면 권한이 즉시 역할이 허용하는 권한으로 전환돼요. 그러면 콘솔을 사용해 amzn-s3-demo-bucket-shared-container 버킷으로 작업할 수 있지만, Destination의 다른 리소스로는 작업할 수 없어요. David가 역할을 사용하는 동안에는 Originating 계정의 power-user 권한도 사용할 수 없어요. 한 번에 한 세트의 권한만 적용될 수 있기 때문이에요.

IAM은 David가 Switch Role 페이지에 들어갈 수 있는 두 가지 방법을 제공해요.

• David는 관리자가 사전 정의된 Switch Role 구성으로 연결되는 링크를 받아요. 이 링크는 Create role 마법사의 마지막 페이지나 크로스 계정 역할의 Role Summary 페이지에서 관리자에게 제공돼요. 이 링크를 선택하면 David는 Account ID와 Role name 필드가 이미 채워진 Switch Role 페이지로 이동해요. David가 해야 할 일은 Switch Roles를 선택하는 것뿐이에요.
• 관리자가 링크를 이메일로 보내지 않고 Account ID 번호와 Role Name 값을 보내요. 역할을 전환하려면 David가 값을 직접 입력해야 해요. 이는 다음 절차에 나와 있어요.

역할 맡기 (To assume a role)

1. David는 Originating 계정의 일반 사용자로 AWS Management Console에 로그인해요.
2. 관리자가 이메일로 보낸 링크를 선택해요. 이렇게 하면 David는 계정 ID나 별칭과 역할 이름 정보가 이미 채워진 Switch Role 페이지로 이동해요. —또는— David는 탐색 모음에서 이름(Identity 메뉴)을 선택한 뒤 Switch Roles를 선택해요.
3. David가 이 방식으로 Switch Role 페이지에 처음 접근하는 경우 먼저 최초 실행 Switch Role 페이지에 도달해요. 이 페이지는 역할 전환이 사용자가 AWS 계정 전반의 리소스를 관리할 수 있게 하는 방법에 대한 추가 정보를 제공해요. David는 이 페이지에서 Switch Role을 선택해 나머지 절차를 완료해야 해요.
4. 다음으로 역할에 접근하기 위해 David는 Destination 계정 ID 번호(999999999999)와 역할 이름(UpdateData)을 직접 입력해야 해요.
5. 또한 David는 IAM에서 현재 활성화된 역할과 관련 권한을 모니터링하고 싶어해요. 이 정보를 추적하기 위해 Display Name 텍스트 상자에 Destination을 입력하고 빨간색 색상 옵션을 선택한 뒤 Switch Role을 선택해요.
6. 이제 David는 Amazon S3 콘솔로 Amazon S3 버킷 또는 UpdateData 역할이 권한을 가진 다른 리소스로 작업할 수 있어요.
7. 작업이 끝나면 David는 원래 권한으로 돌아갈 수 있어요. 그러려면 탐색 모음의 Destination 역할 표시 이름을 선택한 뒤 Back to David @ 111111111111을 선택해요.
8. 다음에 David가 역할을 전환하려고 탐색 모음의 Identity 메뉴를 선택하면 지난번의 Destination 항목이 여전히 남아 있는 것을 볼 수 있어요. 계정 ID와 역할 이름을 다시 입력하지 않고 그 항목을 선택해 즉시 역할을 전환할 수 있어요.

역할 전환 (AWS CLI)

David가 명령줄에서 Destination 환경에서 작업해야 한다면 AWS CLI를 사용해 그렇게 할 수 있어요. aws sts assume-role 명령을 실행하고 역할 ARN을 전달해 그 역할에 대한 임시 보안 자격 증명을 얻어요. 그런 다음 해당 자격 증명을 환경 변수에 구성해 이후 AWS CLI 명령이 역할의 권한으로 작동하게 해요. David가 역할을 사용하는 동안에는 Originating 계정의 power-user 권한을 사용할 수 없어요. 한 번에 한 세트의 권한만 적용될 수 있기 때문이에요.

모든 액세스 키와 토큰은 예시일 뿐이며 보여진 대로 사용할 수 없다는 점에 유의하세요. 사용자 환경에서 적절한 값으로 바꿔야 해요.

역할 맡기 (To assume a role)

1. David가 명령 프롬프트 창을 열고 다음 명령을 실행해 AWS CLI 클라이언트가 작동하는지 확인해요.

aws help

참고 – David의 기본 환경은 aws configure 명령으로 만든 기본 프로필의 David 사용자 자격 증명을 사용해요. 자세한 내용은 _AWS Command Line Interface User Guide_의 "Configuring the AWS Command Line Interface"를 참고하세요.

2. David는 다음 명령을 실행해 Destination 계정의 UpdateData 역할로 전환해요. 역할을 만든 관리자로부터 역할 ARN을 받았어요. 이 명령은 세션 이름도 제공해야 하며, 원하는 텍스트를 선택할 수 있어요.

aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateData" --role-session-name "David-ProdUpdate"

3. David는 출력에서 다음과 같은 내용을 보게 돼요.

{
    "Credentials": {
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "SessionToken": "AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLE
CvSRyh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDy
EXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3Uuysg
sKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87e
NhyDHq6ikBQ==",
        "Expiration": "2014-12-11T23:08:07Z",
        "AccessKeyId": "AKIAIO...MPLE"
    }
}

4. David는 출력의 Credentials 섹션에서 필요한 세 가지 값을 확인해요. AccessKeyId, SecretAccessKey, SessionToken
5. David는 이후 호출에서 이 매개변수를 사용하도록 AWS CLI 환경을 구성해야 해요. 자격 증명을 구성하는 다양한 방법에 대한 정보는 "Configuring the AWS Command Line Interface"를 참고하세요. aws configure 명령은 세션 토큰 캡처를 지원하지 않으므로 사용할 수 없어요. 하지만 구성 파일에 정보를 직접 입력할 수는 있어요. 이것은 상대적으로 짧은 만료 시간을 가진 임시 자격 증명이므로 현재 명령줄 세션의 환경에 추가하는 것이 가장 쉽다.
6. 세 값을 환경에 추가하려면 David가 이전 단계의 출력을 다음 명령에 잘라 붙여넣어요. 세션 토큰 출력의 줄 바꿈 문제를 해결하려면 간단한 텍스트 편집기에 붙여넣는 것이 좋아요. 명확성을 위해 여기서는 줄 바꿈되어 표시되지만 반드시 단일 긴 문자열로 추가해야 해요. 다음 예시는 환경 변수를 만드는 명령이 "set"인 Windows 환경에서 주어진 명령을 보여줘요. Linux나 macOS 컴퓨터에서는 "export" 명령을 사용하면 돼요. 예시의 다른 모든 부분은 세 환경 모두에서 유효해요. Tools for Windows Powershell 사용에 대한 자세한 내용은 "Switch to an IAM role (Tools for Windows PowerShell)"을 참고하세요.

set AWS_ACCESS_KEY_ID=AKIAIO...MPLE
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
set AWS_SESSION_TOKEN=AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvS
Ryh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXA
MPLEKEY9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UusKd
EXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLENhykxiHen
DHq6ikBQ==

7. 이 시점부터 이후 명령은 해당 자격 증명이 식별하는 역할의 권한으로 실행돼요. David의 경우 UpdateData 역할이 돼요.
8. 중요 – 자주 사용하는 구성 설정과 자격 증명을 AWS CLI가 유지 관리하는 파일에 저장할 수 있어요. 자세한 내용은 _AWS Command Line Interface User Guide_의 "Using existing configuration and credentials files"을 참고하세요.
9. Destination 계정의 리소스에 접근하는 명령을 실행해요. 이 예시에서 David는 다음 명령으로 S3 버킷의 내용을 나열해요.

aws s3 ls s3://shared-container

Amazon S3 버킷 이름은 전 세계적으로 고유하므로 버킷을 소유한 계정 ID를 지정할 필요가 없어요. 다른 AWS 서비스의 리소스에 접근하려면 해당 서비스의 AWS CLI 문서에서 리소스를 참조하는 데 필요한 명령과 구문을 참고하세요.

AssumeRole 사용 (AWS API)

David가 코드에서 Destination 계정을 업데이트해야 할 때 AssumeRole 호출을 만들어 UpdateData 역할을 맡아요. 이 호출은 Destination 계정의 amzn-s3-demo-bucket-shared-container 버킷에 접근하는 데 사용할 수 있는 임시 자격 증명을 반환해요. 이 자격 증명으로 David는 amzn-s3-demo-bucket-shared-container 버킷을 업데이트하는 API 호출을 할 수 있어요. 하지만 Originating 계정에서 power-user 권한을 갖고 있어도 Destination 계정의 다른 리소스에 접근하는 API 호출은 할 수 없어요.

역할 맡기 (To assume a role)

1. David는 애플리케이션의 일부로 AssumeRole을 호출해요. UpdateData ARN인 arn:aws:iam::999999999999:role/UpdateData를 지정해야 해요.
2. AssumeRole 호출의 응답에는 AccessKeyId와 SecretAccessKey가 있는 임시 자격 증명이 포함돼요. 또한 자격 증명이 만료되어 새로 요청해야 하는 시점을 나타내는 Expiration 시간도 포함돼요. AWS SDK로 역할 체인을 설정하면 많은 자격 증명 공급자가 만료 전에 자격 증명을 자동으로 새로 고쳐요.
3. 임시 자격 증명으로 David는 s3:PutObject 호출을 만들어 amzn-s3-demo-bucket-shared-container 버킷을 업데이트해요. API 호출에 AuthParams 매개변수로 자격 증명을 전달해요. 임시 역할 자격 증명은 amzn-s3-demo-bucket-shared-container 버킷에 대한 읽기·쓰기 접근만 갖고 있으므로 Destination 계정의 다른 모든 작업은 거부돼요.
4. 코드 예시(Python 사용)는 "Switch to an IAM role (AWS API)"을 참고하세요.

추가 리소스 (Additional resources)

다음 리소스는 이 튜토리얼의 주제에 대해 더 배우는 데 도움이 될 수 있어요.

• IAM 사용자에 대한 자세한 내용은 "IAM Identities"를 참고하세요.
• Amazon S3 버킷에 대한 자세한 내용은 _Amazon Simple Storage Service User Guide_의 "Create a Bucket"을 참고하세요.
• 신뢰 영역(신뢰하는 조직 또는 계정) 밖의 계정에 있는 프린시펄이 역할을 맡을 접근 권한이 있는지 알아보려면 "IAM Access Analyzer란 무엇인가요?"를 참고하세요.

요약 (Summary)

크로스 계정 API 접근 튜토리얼을 완료했어요. 다른 계정과 신뢰를 설정하는 역할을 만들고 신뢰받는 엔터티가 취할 수 있는 작업을 정의했어요. 그런 다음 어떤 IAM 사용자가 역할에 접근할 수 있는지 제어하도록 역할 정책을 수정했어요. 그 결과 Originating 계정의 개발자는 임시 자격 증명을 사용해 Destination 계정의 amzn-s3-demo-bucket-shared-container 버킷을 업데이트할 수 있어요.

더 알아보기 (Learn more)

• IAM 역할
• IAM 역할 문제 해결
• iam:PassRole과 신뢰 정책 예시
• AWS에서 역할 전환(콘솔)