WiseN

AWS 업데이트 읽어주기 20년-9월 / S3 Object Ownership 기능 알아보기

Oct 15, 2020   |   AWS

작성자_최준승

페이스북 공유하기 트위터 공유하기
Blog thumbnail

안녕하십니까. 오늘은 S3와 관련된 새로운 옵션 하나를 살펴보려고 합니다. 어떻게 보면 중요하고 어떻게 보면 아주 지엽적인 부분이라서, 최대한 간결하게 핵심 위주로 짚고 넘어가겠습니다.

 

 

AWS 관리 콘솔에서 S3의 Permission 탭에 가시면 위와 같은 메뉴가 새로 생겼습니다. 2가지 선택항목이 보이네요. 기본값은 Object writer입니다. 그럼 Bucket owner preferred를 선택하면 어떻게 될까요? 이 질문에 대한 답을 드리는 것이 오늘 포스팅의 목적입니다.

 

본론에 들어가기 앞서, 몇가지 배경지식을 숙지할 필요가 있습니다. 우선 S3 서비스에서 컨트롤 하는 단위 객체는 무엇이 있을까요? Bucket과 Object. 그럼 저 단위 객체들의 속성을 바꾸거나 접근 권한을 제어하는 방법에는 무엇이 있을까요? ACL과 Bucket Policy가 있습니다. ACL을 좀 더 엄밀히 나누면 Bucket ACL과 Object ACL이 있구요. 이 중 Object ACL은 해당 객체의 Owner가 누구냐. 어떤 AWS Account에서 해당 객체에 접근(읽기/쓰기 등)할 수 있느냐 등을 정의하게 됩니다.

 

​AWS 계정이 하나만 있다면 사실 저런 부분들을 크게 신경쓰지 않아도 됩니다만, 요새 트렌드는 그렇지가 않습니다. 같은 회사 내에서 여러개의 AWS 계정을 쓰기도 하고, 다른 회사의 AWS 계정에서 데이터를 들고 와야 할 경우도 종종 있죠. 이렇게 多계정이 혼재된 환경에서 S3 객체가 오고 갔을때, 저 Object ACL의 Owner를 일관된 정책으로 관리해야하는 문제는 생각보다 복잡합니다. 

 

자, 다시 원점으로 돌아와서.. H, I, J 라는 AWS 계정이 있고.. I, J라는 계정 권한(IAM)으로 H 계정 내에 있는 S3 Bucket에 객체를 업로드한다고 가정해 보겠습니다. PutObject(업로드)를 수행할때 별다른 파라미터를 정의하지 않는다면, 해당 객체들의 Owner(Object ACL)는 각각의 I, J가 되고.. 안타깝게도 H 계정의 권한으로는 읽기도, 권한 변경도 할 수 없게 됩니다. 이는 종종 일어나는 일입니다.

 


 

그래서 어떻게 하냐면 보통 업로드할때 별도의 권한을 정의합니다. 이때 하나하나 정의하기는 어려우니 사전정의된(Predefine) 권한 Set을 참조하는데요. 이것을 Canned ACL이라고 합니다. 아래와 같은 것들이 있구요.

 


  

이 중 보통 bucket-owner-full-control을 많이 활용합니다. 업로드시 이 값을 acl 파라미터값으로 할당해 주면, 자연스럽게 Bucket Owner인 H 계정의 사용자도 타 계정으로부터 업로드한 객체에 접근할 수 있게 됩니다.


자, 이제 오늘글 맨앞에서 보여드렸던 Object Ownership 기능이 무엇인지 설명드릴 수 있게 되었군요. 타 AWS 계정에서 bucket owner-full-control이라고 하는 canned acl을 통해 해당 버킷에 객체를 업로드했을때, 해당 객체의 Owner가 누구로 정의되는지를 결정하는 옵션입니다. 먼저 기본값인 Object Writer로 설정되었을때를 봅시다.




Object Owner는 e437로 시작하는 계정이군요. 그리고 맨 아래 타 AWS 계정이 컨트롤할 수 있는 권한이 추가로 정의되어 있는데. 이 계정은 8582로 시작합니다. 여기서 8582로 시작하는 계정은 버킷이 존재하는 계정이구요. e437은 업로드한 계정이네요. 즉, 객체의 소유주(Owner)는 업로드한 사용자이고 이를 보완하기 위해 버킷이 존재하는 계정의 추가 권한이 부여되어 있습니다. 이번엔 Object Ownership 값을 Bucket owner preferred로 설정한 경우를 살펴봅시다.




이번에는 객체의 Owner가 8582로 시작하는 계정으로 되어 있네요. 이는 버킷이 존재하는 계정을 뜻하구요. 이렇게 되면 해당 객체를 마치 동일한 AWS 계정의 사용자가 업로드한것처럼 자유롭게 컨트롤할 수가 있게 됩니다. 만일 해당 버킷에 객체를 업로드하는 타계정이 2개가 아니라 20개라면? 200개라면? 이 객체 권한이 표준화되었느냐 안되어 있느냐는 관리난이도상 엄청난 차이를 불러옵니다. 이해가 가시나요?


오늘 내용을 요약하면 이렇습니다. A 계정의 권한으로 B 계정의 S3 버킷에 객체 업로드를 할때, 그리고 업로드시 bucket owner-full-control라고 하는 값을 acl에 파라미터로 정의한다고 가정했을때​, 해당 객체의 owner를 B 계정으로 설정하고 싶다면? Object Ownership의 설정값을 Bucket owner preferred로 해라!

 

여기서 한발 더 나아가서, A 계정의 권한으로 업로드를 수행할때 bucket owner-full-control를 정의하지 않으면 어떻게 될까요? 그럼 의미가 없잖아요? 이 부분은 Bucket Policy에서 강제해주면 됩니다. "s3:x-amz-acl": "bucket-owner-full-control" 일때만 업로드를 할 수 있도록 Condition을 제한하는 것이죠. 그렇게 되면 A 계정의 권한으로 업로드 할때 bucket owner-full-control​ 를 정의하지 않으면 아래와 같은 에러가 발생합니다.


$ aws s3 cp list3.sh s3://gsneotek-s3-test

upload failed: ./list3.sh to s3://gsneotek-s3-test/list3.sh An error occurred (AccessDenied) when calling the PutObject operation: Access Denied

 

이를 통해 업로드하는 쪽에서는 bucket owner-full-control을 강제하고, 업로드된 후에는 (이번에 새로 나온 옵션을 통해) 객체의 owner를 bucket 사용자로 자동 지정되게 함으로써 향후 관리를 손쉽게 만들 수 있습니다. 물론 처음에 잘못 끼워진 단추는 나중에 어떻게든 고칠수는 있겠지만.. 처음부터 잘 배열되도록 유도하면 나중에 손이 안가고 참 좋지 않겠습니까? 

 

그럼 마치겠습니다. 끝!

 

https://docs.aws.amazon.com/AmazonS3/latest/dev/about-object-ownership.html

https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html#canned-acl