https://www.youtube.com/watch?v=pLlX-uxhsXg&t=663 

ㄴ 영상으로 보길 추천

자격 증명

1. 콘솔 엑세스 자격 증명

 

2. 프로그램 방식 엑세스 자격 증명

임시 자격 증명의 경우, IAM role policy와 Permission policy의 교집합임.

IAM role policy = 인증 (Authentication) - 이 사용자가 누구인지

Permission policy = 인가 (Authorization) - 어떤 일을 허가 받았는지

(https://www.youtube.com/watch?v=zIZ6_tYujts&t=1256) -> 조이정 SA, AWS IAM과 친해지기 (레벨200)

IAM User 만들고 in-line policy 추가

All로 하면 모든 ARN에 대해서 AssumeRole을 할 수 있는듯?

 

이제 이 유저는 다른건 하나도 못하고, AssumeRole 하나만 할 수 있다.

이제 IAM User는 sts:AssumeRole 하나의 role만 가지고 있다.

이제 IAM User가 AssumeRole로 임시로 갖다쓸 role을 만들어보자.

 

s3 full access role을 만들어볼거임.

자 여기까지 했음.

이제 터미널에서 방금 만든 s3 full access role을 assume role 하려고 하는데 자꾸 이상한 에러가 뜸.

Not authorized to perform: sts:AssumeRole

(시간 많이 잡아먹음 ㅠ)

 

알고보니...

방금 만든 s3 full access role의 trust relationship 탭에서 IAM user의 어카운트를 적어줘야됨.

 

이미 삭제함 ㅋ

sts를 이용해 임시로 만든 access key, secret key, session token을 콘솔에 등록하면

export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s" $(aws sts assume-role --role-arn arn:aws:iam::045227856381:role/assume-role-test --role-session-name MySessionName --query "Credentials.[AccessKeyId,SecretAccessKey,SessionToken]" --output text))

다음과 같이 aws s3 ls를 할 수 있음.

 

sts 시간을 늘리고 싶다면 콘솔이랑 cli 모두 가능. (cli가 더 범위가 넓은듯)

최소 15분, 최대는 12시간

콘솔에서는 1,2,4시간 중 하나 선택 가능

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html

 

 

그럼 궁금한 점)

1. aws configure 등록할 때는 session token 이런거 등록 안했는데, 이건 어디다 등록 하는거? -> 갖다 쓰나 보지 뭐.

config
credentials (이미 삭제함 ㅋ)

음.. 등록되는 곳이 없는데?

 

2. role의 신뢰 관계가 뭐길래, 이걸 등록하니까 잘 됨?

 

3. 토큰 발급 받은 다음에, 또 토큰 발급 받으려고 하니까 왜 에러가 뜸?

내가 실수했음. 기존 admin 계정으로 access key, secret key 넣어놨었는데, 테스트 하면서 session tokey의 access key, secret key로 교체해서 넣었음.

 

발급받는 토큰에는 s3 full access role만 있고, assumerole이 없어서 그런가...?

ㄴ 그렇지. 

그러면 IAM user가 갖고 있던 기존 role을 덮어씌워버리는건가??? 1시간 후에 한번 보자.

ㄴ IAM user는 assumeRole 갖고 있는거고, 이걸로 만든 session token이 세션 토큰의 엑세스키, 세션 토큰의 비밀키 갖고 있는거임.

https://jost-do-it.tistory.com/entry/AWS-AWS-configure-%EB%93%B1%EB%A1%9D-%EB%B0%8F-AWS-Session-Token-%EB%B0%9C%EA%B8%89

여러 개 잘되는데? ㅡㅡ

ㄴ 당연히 잘되어야지.

 

 

CLI에서 임시 자격 증명 사용법

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_temp_use-resources.html


https://repost.aws/questions/QUOY5XngCtRyOX4Desaygz8Q/not-authorized-to-perform-sts-assumerole

 

 

Not authorized to perform: sts:AssumeRole

Hello guy's, Try to build application with usage custom library: https://sp-api-docs.saleweaver.com/ And receive: ClientError: An error occurred (AccessDenied) when calling the AssumeRole operati...

repost.aws

https://ongamedev.tistory.com/473

 

AWS AssumeRole 설정 안될 때..

An error occurred (AccessDenied) when calling the AssumeRole operation : User: arn:aws:iam::**************:user/ar_user is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::**************:role/test_role 위와 같은 에러는 두 가지

ongamedev.tistory.com

 

----

Identity-based policy : 접근을 하기 위한 정책

Resource-based policy : 접근을 받기 위한 정책

 

하나의 요청을 허용 또는 차단하기 위한 정책을 양쪽에서 다 기술한다면,

 

하나의 어카운트 내에서는, 합집합

크로스 어카운트 내에서는, 교집합의 형태로 검사.

따라서, 한쪽에만 정책이 정의되어있는 경우에는

동일 어카운트의 경우에는 요청이 허용되고 크로스 어카운트 내에서는 요청이 거부된다.

그리고 

  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 카카오스토리 공유하기