<div id="readability-page-1" class="page"><div id="content">
<main role="main">
	
<article id="post-4006">
	
	

	
	
	<div>
		
AWS에서 제공하는 자격 증명의 제공 방식은 크게 사용자 계정의 액세스 키 방식과 IAM 역할(Role)에 대해서 역할 위임(Assume Role)을 하는 두 가지 방식으로 나눌 수 있습니다. AWS SSO는 이러한 방식 중에서 후자를 통해서 마스터 계정으로부터 하위 계정에 대한 권한을 위임하는 것입니다. 물론 이러한 위임 절차는 SSO 서비스가 자동으로 진행하고 있습니다. 저는 이미 앞선 글들을 통해서 이 두 가지 방식을 이용하여 AWS CLI를 안전하게 사용하는 방법을 알아보았습니다.



그렇다면 SSO를 설정하지 못하는, 즉 내가 관리하지 못하는 계정에 대해서 안전하게 권한을 획득하려면 어떻게 해야 할까요? 액세스 키를 발급받아서 사용할 수도 있지만 상대방이 보안을 중요시한다면 함부로 액세스 키를 제공하려고 하지 않을 것입니다. 이러한 상황에서는 먼저 내 계정(A)에서 상대방 계정(B)의 IAM 역할을 위임할 수 있도록 신뢰 관계를 설정하고, 내 계정에 대한 액세스 키를 발급받아서 사용하면 됩니다.



B계정에서 저에게 부여하고 싶은 권한 정책을 생성하고, IAM 역할에 할당합니다. 그리고 이 역할에 다음과 같이 신뢰관계를 작성합니다. 보통 이러한 과정은 상대방이 진행하기 때문에 사실 사용하는 당사자인 제 입장에서 크게 신경쓸 부분은 아닙니다.


<pre aria-describedby="shcb-language-1" data-shcb-language-name="JSON / JSON with Comments" data-shcb-language-slug="json"><code>{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "AWS": "arn:aws:iam::000000000000:root"
 },
 "Action": "sts:AssumeRole",
 "Condition": {
 "StringEquals": {
 "sts:ExternalId": "35e413a2-b7d2-45a3-9126-6fdf4563863d"
 }
 }
 }
 ]
}</code>Code language: JSON / JSON with Comments (json)</pre>


이와 같이 A의 계정에 대해서 B 계정의 IAM 역할을 위임할 수 있는 신뢰관계를 구축하였습니다. 역할 위임의 범위를 축소하려면 root 대신에 역할 arn을 넣거나 계정을 지정할 수 있습니다. 그리고 추가적인 보안을 위해서 역할 위임시에는 ExternalId가 맞는지 확인하도록 조건을 제공하였기 때문에, A 계정에서 역할 위임시에는 이 값을 반드시 전달해야 합니다.



그러면 이제 A 계정의 액세스 키를 사용하여 다음과 같이 역할을 위임할 수 있습니다. 여기서 사용하는 <code>role_arn</code> 값은 B 계정에서 역할이 위임될 IAM 역할의 것입니다.


<pre aria-describedby="shcb-language-2" data-shcb-language-name="JSON / JSON with Comments" data-shcb-language-slug="json"><code>&gt; aws sts assume-role --role-arn &lt;role_arn&gt; \
 --external-id 35e413a2-b7d2-45a3-9126-6fdf4563863d \
 --role-session-name test
{
 "Credentials": {
 "AccessKeyId": "ASIAXXXX",
 "SecretAccessKey": "XXXX",
 "SessionToken": "XXXX",
 "Expiration": "2023-03-19T13:50:27+00:00"
 },
 "AssumedRoleUser": {
 "AssumedRoleId": "AROAXXXX:test",
 "Arn": "&lt;role_arn&gt;/test"
 }
}</code>Code language: JSON / JSON with Comments (json)</pre>


그러면 B 계정에서 사용할 수 있는 세션에 대한 크레덴셜 정보가 출력되는데, 이것을 사용하여 B 계정에서의 명령을 수행할 수 있게 됩니다. 



<hr>



하지만… 이렇게 출력된 정보를 다시 저장하고 갱신하고 하는 과정이 여간 귀찮은게 아닙니다. 그래서 이러한 정보들을 사전에 CLI에 설정해놓고 손쉽게 인증 정보를 갱신할 수 있습니다. 먼저 A 계정에 대한 액세스 키 정보를 토대로 앞선 글들과 같이 demo 프로파일을 생성합니다. 그리고 B 계정에서 위암할 역할에 대한 정보를 별도의 프로파일로 생성합니다. [<a href="https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html" target="_blank" rel="noreferrer noopener nofollow">공식 문서</a>]


<pre aria-describedby="shcb-language-3" data-shcb-language-name="Bash" data-shcb-language-slug="bash"><code>&gt; vi ~/.aws/config
[profile test]
external_id=35e413a2-b7d2-45a3-9126-6fdf4563863d
role_arn=&lt;role_arn&gt;
role_session_name=test
source_profile=demo
region=ap-northeast-2</code>Code language: Bash (bash)</pre>


<code>source_profile</code> 항목에 demo 프로파일을 지정함으로써, 역할 위임 프로파일 test는 demo 프로파일의 크레덴셜을 사용하여 위임 과정을 진행하라고 명시하는 것입니다. 그러면 앞서 <code>sts</code> 명령을 사용하여 크레덴셜을 취득하고 복사하고 저장하고 사용하는 과정 자체를 한 번에 건너 뛸 수 있게 됩니다.


<pre aria-describedby="shcb-language-4" data-shcb-language-name="Bash" data-shcb-language-slug="bash"><code>&gt; aws s3 ls --profile test
2023-03-07 09:46:21 aws-athena-query-xxx
2023-03-07 09:46:21 cf-templates-xxx
...</code>Code language: Bash (bash)</pre>


이렇게 역할 위임을 통해서 내 계정으로부터 다른 계정의 권한을 취득하고 사용할 수 있습니다. 다만 현재 버그 때문인지, AWS Vault로는 역할 위임 프로파일이 제대로 동작하지 않고 있으므로 참고바랍니다 [<a rel="noreferrer noopener nofollow" href="https://github.com/99designs/aws-vault/issues/978" target="_blank">링크</a>].
	</div>

	
	
	

	</article>


	<nav aria-label="Posts">
		<h2>Post navigation</h2>
		
	</nav>
</main>



	</div></div>

Lamanus' Archive

AWS에서 제공하는 자격 증명의 제공 방식은 크게 사용자 계정의 액세스 키 방식과 IAM 역할(Role)에 대해서 역할 위임(Assume Role)을 하는 두 가지 방식으로 나눌 수 있습니다. AWS SSO는 이러한 방식 중에서 후자를 통해서 마스터 계정으로부터 하위 계정에 대한 권한을 위임하는 것입니다. 물론 이러한 위임 절차는 SSO 서비스가 자동으로 진행하고 있습니다. 저는…
Continue reading AWS 크레덴셜 안전하기 사용하기 – Assume Role

AWS 크레덴셜 안전하기 사용하기 – Assume Role

댓글