AWS S3 맛보기
음... 취업하기 전에 진행했었던 프로젝트에서 AWS Resource 관련 정리해 놓은 파일이 놀고있길래..
블로그에 정리해볼려고 한다. (안하면 그대로 썩어 없어질판)
그 첫번째는 S3이다.
S3
확장성, 가용성, 보안 등 여러 측면에서 강점을 가진 AWS의 클라우드 기반 객체 스토리지 서비스이다.
(뭐이리 장점이 많아?)
!S3 버킷은 기본적으로 전역적(이 세상에서)으로 이름이 고유해야 한다. 이는 버킷명이 S3에 접근할 수 있는 도메인이 되기 때문이다.
이게 무슨말이냐면, S3 버킷명에 접근할 수 있는 URL에 S3 버킷명이 포함되기 때문에 전역적으로 고유해야 한다는 말이다.
고유하지 않으면 어떻게 동일한 URL에 대해 구분할 수 있겠는가..
S3 액세스
일단 잘 모르겠으면 퍼블릭 액세스는 차단하는 것이 좋다.
But, 뭐든지 상황에 맞춰서 해야 한다.
필요에 의해 버킷 내 객체가 자유롭게 접근이 가능해야 한다면, 버킷을 퍼블릭 으로 설정해야 하는 경우가 있다.
그럴 경우에는 모든 퍼블릭 액세스 차단 을 체크 해제하면 된다.
체크만 해제하면 버킷이 퍼블릭 상태가 되냐?
아니다.
버킷 정책을 설정해 주어야 한다.
해당 정책에 대해 설명하자면,
모든 Principal(AWS 주체: IAM 사용자 등)과 S3:GetObject 하는 행동, Resource (AWS에서 사용되는 resource)에 대해 버킷 액세스 권한을 부여하는 정책이다.
Reource는 예시에서 OO 이라는 버킷의 ARN을 통해, ‘*’모든 객체에 허용을 해주는 것이다.
따라서 해당 정책을 설정하면 버킷은 퍼블릭 상태가 된다.
(단, 버킷이 퍼블릭 상태가 되기까지 시간이 소요되고, 정책을 편집한 직후에 퍼블릭 상태로 바로 바뀌지 않을 수 있다는 것을 확인했다.)
정책은 본인이 직접 외워서 작성할 필요없이, AWS에서는 정책 생성기를 기본적으로 제공하니 이것을 이용하면 옵션만으로 버킷 정책 json이 자동으로 생성된다. (이런 점이 너무 좋다.)
다음은 CORS 정책을 설정해야한다.
프로젝트 할 때마다 우릴 괴롭히는 그 CORS 맞다...
PUT, POST, GET 요청에 대해 허용해주었고, Origins는 해당 서비스의 origin을 적어주면 된다. 테스트와 변경사항이 있을 경우를 대비해(*)로 모두 허용해주었다.
또한 허용하는 header도 설정해 줄 수 있다.
S3에 대해 한가지 알아두면 좋은 점은 버킷 내에 폴더 생성이라고 명시되어 있지만, S3는 실제로 폴더를 생성하지 않는다. 폴더를 생성하여 생기는 경로는 사실 하나의 고유한 객체이다.
프로젝트를 진행 하면서 확인한 버킷의 상태는 다음과 같다.
- 퍼블릭 : 해당 버킷이 공개적이며, 모든 주체가 접근할 수 있다. (보안위험)
- 객체를 퍼블릭으로 설정할 수 있음 : 버킷 생성시에, 액세스 접근 차단을 해제하면 다음과 같은 상태가 된다. 버킷 정책을 통해 버킷을 퍼블릭으로 만들 수 있다.
- 버킷 및 객체가 퍼블릭이 아님 : 사용자가 허용한 주체만이 버킷에 접근할 수 있다. (버킷 정책)
비공개 버킷 접근하기
비공개 버킷은 프로그래밍적 방법으로는 버킷의 key를 통해 접근할 수 있으며, 액세스키와 비밀 액세스키를 이용하여 권한을 얻은 클라이언트 객체를 통해 접근할 수 있다.
해당 키는 IAM 에서 사용자의 버킷에 대한 권한을 설정하고 버킷에 대한 액세스 키를 발급받으면 된다.
ex) 특정 AWS 주체 arn에 대해 버킷의 모든 객체에 대해 S3:GetObject 권한을 부여
역시, 정책 생성기를 통해 정책을 생성해 주면 되겠다!
요기까지... 이론적인 내용보단 실제 설정을 하면서 겪었던 내용들 위주로 적었다.
다른 리소스들도 이런식으로 가볍게 적어볼까 한다.