You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
라는 예시를 활용해서 아래에 있는 "Resource"를 내가 접근하고 싶은 버킷명으로 바꿔주었다.
해석을 해 보자면 모든 다른 리소스에 대해서는 ListAllMyBuckets와 GetBucketLocation만 허용하지만 아래 특정한 리소스에 관해서는 S3에서 할 수 있는 모든 액션을 허용한다는 거다.
IAM 역할과 신뢰관계도 위 링크를 따라 설정해주면 된다.
! IAM 정책과 역할을 기술하는 JSON에서는 Principal 혹은 NonPrincipal을 사용할 수 없다 !
중요한 건 Bucket 정책
요약하자면 IAM 정책에서는 어떠한 Bucket에 접근하여 어떤 작업(Action)까지 허용하는가에 대한 기준을 적으면 되고,
IAM 역할에서는 그것을 실행하는 주체를 정하기 때문에 Lambda를 선택해야 한다.
특정 Bucket에 특정 역할만 접근할 수 있다는 제한은 Bucket 정책에서 두는 것이다.
특정 Lambda 함수로 접근해야 한다는 문제라 Lambda 함수의 ARN을 적어서 제한해야 하는가, 그걸로 식별해야 하는가 했는데 의외로 어디에서도 필요로 하지 않았다..
이제 생성한 Bucket에 가서 권한->Bucket 정책을 눌러주면 JSON 에디터가 나온다.
여기서 실수했다간 Bucket을 만든 당사자도 접근불가를 하게 되니 각!별!히! 주의해야 한다.
Bucket에 대한 접근 권한을 제한하는 데에는 2 가지 방법이 있다.
1. Deny + NotPrincipal
2. Deny + Principal + Condition
처음엔 1번 방법을 이용해 접근을 금지하려고 했으나 role ARN과 assumed-role ARN이 둘 다 필요하기 때문에 관뒀다.
When using the NotPrincipal element, you must include both ARNs for this approach to work, and the second of these ARNs should include a variable name.
(대체 어디가야 assumed-role ARN과 session name을 찾을 수 있는지 아직 찾지 못했기 때문이다)
게다가 내가 적당히 번역한(Markdown 완전 아작나서 귀찮..아서 수정 안할거라 보기 싫을 수 있다. 읽어 볼 사람들은 대충 내용만 파악하고 자세한 것은 원문 글을 읽으면 된다) AWS 특정 IAM 역할로 S3 버킷에 대한 접근을 제한하기 (적당히 해석)에도 나와있는데 NotPrincipal을 사용하면 자주 갱신(?)해줘야 한단다. 그래서 이 사람도 되도록이면 Condition으로 제한하라고 제안하고 있다. AWS 공식 도큐멘트에도 되도록이면 NotPrincipal을 사용하지 않는 것을 추장한다고 적혀있다.
In general, they attempt to do this the same way that they would with an IAM user: use a bucket policy to explicitly Deny all Principals (users and roles) to which they do not want to grant access. The drawback with this approach is the required maintenance of the bucket policy. If a new IAM user were added to the account with “s3:*” for the Action, the user would be granted access to the bucket.
두 번째는 Deny로 명시적인 접근 거부를 기본으로 하면서 Principal로 와일드카드(*)와 함께 조건문을 적는 것이다.
이 방법은 roleid만을 필요로 하기 때문에 꽤나 편리하다.
roleid 얻기
이건 콘솔이 아니라 AWS-CLI를 사용해야 한다.
커맨드로 처음 aws를 사용할 때에는 configure를 해 주어야 한다.
access key
secret access key
region
output style: json
다 끝나면
$ vim ~/.aws/configure
에서 역할 전환할 계정 정보를 적어야 한다.
나 같은 경우에는 개발자 계정(admin)으로 전환해야 해서 그 정보를 적었다.
그러면
$ aws iam get-role --profile [switched_account_name] --role-name [role_name]
오늘 과제는 아래와 같다.
임의의 S3 버킷 생성하기
참고로 S3란 데이터들이 들어있는 저장소라 보면 된다.
버킷 만들기
hello-lambda-test-bucket
이라 해준다허용된 것보다 많은 버킷을 생성하려고 시도했습니다.
라는 에러가 뜨면서 버킷 생성을 못했다'허용된 것보다 많은 버킷을 생성하려고 시도했습니다' TooManyBuckets error일 때 버킷 할당량 변경하기
콘솔에 로그인 한 상태에서
Service Quotas
로 이동AWS 서비스
S3 검색
Buckets 선택
할당량 증가 요청
눌러서 200이든 500이든 적어서 늘리기최근 할당량 변경 요청
의 상태가할당량이 요청됨
이 되면 버킷 작성이 가능해진다퍼블릭 액세스 제한을 해 주고 생성
시작하기
를 누르고 sample_text.txt를 업로드IAM 역할을 이용해 Lambda함수가 S3 버킷에 접근할 수 있게 하기
오만가지 도큐멘트를 읽었는데 IAM정책과 역할을 설정하는데에는 이만한 글이 없었다.
(사실 오만가지 읽은 이유는 IAM 정책과 역할에서 Lambda함수를 특정해야하는가 고민했기 때문이었다)
Amazon S3 버킷에 대한 액세스 권한을 Lambda 실행 역할에 허용하려면 어떻게 해야 합니까?
정책을 기술할 때
라는 예시를 활용해서 아래에 있는
"Resource"
를 내가 접근하고 싶은 버킷명으로 바꿔주었다.해석을 해 보자면 모든 다른 리소스에 대해서는
ListAllMyBuckets
와GetBucketLocation
만 허용하지만 아래 특정한 리소스에 관해서는S3
에서 할 수 있는 모든 액션을 허용한다는 거다.IAM 역할과 신뢰관계도 위 링크를 따라 설정해주면 된다.
! IAM 정책과 역할을 기술하는 JSON에서는
Principal
혹은NonPrincipal
을 사용할 수 없다 !중요한 건 Bucket 정책
요약하자면 IAM 정책에서는 어떠한 Bucket에 접근하여 어떤 작업(Action)까지 허용하는가에 대한 기준을 적으면 되고,
IAM 역할에서는 그것을 실행하는 주체를 정하기 때문에 Lambda를 선택해야 한다.
특정 Bucket에 특정 역할만 접근할 수 있다는 제한은 Bucket 정책에서 두는 것이다.
특정 Lambda 함수로 접근해야 한다는 문제라 Lambda 함수의 ARN을 적어서 제한해야 하는가, 그걸로 식별해야 하는가 했는데 의외로 어디에서도 필요로 하지 않았다..
이제 생성한 Bucket에 가서 권한->Bucket 정책을 눌러주면 JSON 에디터가 나온다.
여기서 실수했다간 Bucket을 만든 당사자도 접근불가를 하게 되니 각!별!히! 주의해야 한다.
Bucket에 대한 접근 권한을 제한하는 데에는 2 가지 방법이 있다.
처음엔 1번 방법을 이용해 접근을 금지하려고 했으나
role ARN
과assumed-role ARN
이 둘 다 필요하기 때문에 관뒀다.(대체 어디가야
assumed-role ARN
과session name
을 찾을 수 있는지 아직 찾지 못했기 때문이다)게다가 내가 적당히 번역한(
Markdown
완전 아작나서 귀찮..아서 수정 안할거라 보기 싫을 수 있다. 읽어 볼 사람들은 대충 내용만 파악하고 자세한 것은 원문 글을 읽으면 된다) AWS 특정 IAM 역할로 S3 버킷에 대한 접근을 제한하기 (적당히 해석)에도 나와있는데NotPrincipal
을 사용하면 자주 갱신(?)해줘야 한단다. 그래서 이 사람도 되도록이면 Condition으로 제한하라고 제안하고 있다. AWS 공식 도큐멘트에도 되도록이면NotPrincipal
을 사용하지 않는 것을 추장한다고 적혀있다.두 번째는
Deny
로 명시적인 접근 거부를 기본으로 하면서Principal
로 와일드카드(*)와 함께 조건문을 적는 것이다.이 방법은
roleid
만을 필요로 하기 때문에 꽤나 편리하다.roleid 얻기
이건 콘솔이 아니라
AWS-CLI
를 사용해야 한다.커맨드로 처음 aws를 사용할 때에는 configure를 해 주어야 한다.
다 끝나면
에서 역할 전환할 계정 정보를 적어야 한다.
나 같은 경우에는 개발자 계정(admin)으로 전환해야 해서 그 정보를 적었다.
그러면
으로 역할의 모든 정보를 출력할 수 있다.
거기에서
roleid
를 가져와위 JSON에 대입한다.
!
roleid
뒤에:*
를 적지 않으면 세션까지 제한되기 때문에 본인이 특정한 역할을 특정 Lambda 함수에 적용하더라도access denied
당하니 주의해야 한다 !역할을 원하는 Lambda함수에 적용하면 끝
이걸 알아내겠다고 이틀을 고생했는데 막상 하고 나니 정책 JSON이 너무나도 간단해서 맥이 풀렸다.
하지만 오만가지 도큐멘트를 읽으면서 온갖 정보를 머리에 인풋했기 때문에 성장은 했을 것이다.
The text was updated successfully, but these errors were encountered: