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가 더 범위가 넓은듯)
콘솔에서는 1,2,4시간 중 하나 선택 가능
그럼 궁금한 점)
1. aws configure 등록할 때는 session token 이런거 등록 안했는데, 이건 어디다 등록 하는거? -> 갖다 쓰나 보지 뭐.
음.. 등록되는 곳이 없는데?
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이 세션 토큰의 엑세스키, 세션 토큰의 비밀키 갖고 있는거임.
여러 개 잘되는데? ㅡㅡ
ㄴ 당연히 잘되어야지.
CLI에서 임시 자격 증명 사용법
https://repost.aws/questions/QUOY5XngCtRyOX4Desaygz8Q/not-authorized-to-perform-sts-assumerole
https://ongamedev.tistory.com/473
----
Identity-based policy : 접근을 하기 위한 정책
Resource-based policy : 접근을 받기 위한 정책
하나의 요청을 허용 또는 차단하기 위한 정책을 양쪽에서 다 기술한다면,
하나의 어카운트 내에서는, 합집합
크로스 어카운트 내에서는, 교집합의 형태로 검사.
따라서, 한쪽에만 정책이 정의되어있는 경우에는
동일 어카운트의 경우에는 요청이 허용되고 크로스 어카운트 내에서는 요청이 거부된다.
그리고
'CLOUD > AWS Cloud' 카테고리의 다른 글
S3 presigned URL (발급받은 URL로 S3에 바로 업로드) (0) | 2023.08.25 |
---|---|
세션 매니저는 https, route table은 내부->외부, public ip는 외부->내부 (private에 ec2 있어도 udp는 통신가능) (0) | 2023.08.20 |
[펌] AWS S3에 Vue.js 앱 정적 호스팅하기 (0) | 2023.08.10 |
Amazon RDS 정리 (0) | 2023.08.05 |
[펌] 장기 자격 증명(Access Key) & 임시 자격 증명 (AssumeRole) (0) | 2023.07.20 |
최근댓글