00pen

예전에 s3에 이미지를 올려놓고, 퍼블릭에서 엑세스 가능하도록 개발을 하는 경우가 많았는데 그럴 때마다 모든 퍼블릭 엑세스 차단을 풀고, ACL(엑세스 제어 목록)에 모든 유저를 열어서 개발한 적이 있었는데 생각해보면 보안상 문제가 있을 것 같으므로 이번에 사이드 프로젝트를 하면서 어떻게 하면 퍼블릭 유저가 할 수 있는 걸 최소화할 수 있을까 고민해 봤다.

일단 ACL에서는 모든 유저에게 어떤 권한도 주지 않았다. 버킷에 유저가 접근 가능해야하는 파일과 접근 불가능해야하는 파일이 같이 있을 수도 있기 때문에 그렇게 하였고, 오직 버킷 소유자만 객체, 객체 ACL에 읽기,쓰기가 가능하도록 해놓았다. 그리고 퍼블릭 액세스를 가능하게 해야하는 파일들은 파일을 업로드 하는 어플리케이션 서버에서 지정하도록 해놓았다. (Spring 서버에서 putObject할 때 PublicRead로 객체 읽기를 열어두도록 지정해줄 수 있다.)

새 ACL, 임의의 ACL을 통해 부여된 버킷 및 객체에 대한 퍼블릭 액세스 차단은 풀어놔야 publicRead로 객체를 만들 수 있었다. 액세스 지점 정책은 따로 endpoint를 두어서 S3에 대한 접근을 관리할 수 있는 기능 같은데 사용하고 있지는 않기 때문에 그냥 차단해 놓았다.

영어를 번역해 놓아서 그런지 ACL(엑세스 제어 목록), 객체, 객체 ACL 등등 말이 되게 어렵게 되어있는 것 같다.

참고글
S3 개념 및 용어 관련 정리
https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-S3-%EB%B2%84%ED%82%B7-%EC%83%9D%EC%84%B1-%EC%82%AC%EC%9A%A9%EB%B2%95-%EC%8B%A4%EC%A0%84-%EA%B5%AC%EC%B6%95#ACL_(Access_Control_List)

spring에서 s3에 이미지 업로드
https://www.sunny-son.space/spring/Springboot%EB%A1%9C%20S3%20%ED%8C%8C%EC%9D%BC%20%EC%97%85%EB%A1%9C%EB%93%9C/

이전까지는 사이드 프로젝트나 토이 프로젝트를 할 때 혼자 했었다. 근데 이제는 프론트엔드 개발자와 디자이너, 기획자 분들과 함께 하다보니 프로젝트가 온전히 나의 것이 아닌 상황이 되었고, 이 프로젝트를 위한 aws 계정을 파는 것까지는 아니더라도, 회사에서 쓰는 것처럼 내 계정을 root 계정으로 돌리고, 다른 분들께 aws console에 접속할 수 있는 권한과 관리자 권한을 드려야 한다는 생각이 들었다. 나도 이제 시작이지만 처음 이런 상황에 마주하게 되어서 조그마한 프로젝트지만 혼자하는 프로젝트가 아닌 분들께 도움이 되지 않을까 하는 생각에 기록해본다.

1. aws organization을 사용할 상황은 아니다.
 처음에는 막막해서 그냥 회사 dev aws에 내 계정은 어떻게 설정되어 있는지를 보았다. 들어가기 전에는 organziation을 만들어야 하는건가 싶었는데 그건 조직이 커졌을 때 devops 조직과, 그냥 개발팀을 나눈다던지, 결제 관련해서 나누어야 하는 상황일 때 쓰는 것이였다. 그래서 이건 pass.

2. 일단 토이프로젝트라서 아무 것도 만들어져있지 않은 상황이기 때문에 어느정도 개발된 후에 aws를 만들어도 된다.
 백도 프론트도 이제 처음 시작이기 때문에 github로 코드를 공유하면서 local에서 개발한 후, 어느정도 기반이 되었을 때에나 aws에 서버를 만들어도 늦지 않을 것 같다.

3. iam을 통해 관리자 group을 만들고, 자신을 user에 추가하고, 동료분들도 user에 추가한다.
 내 계정엔 admin이라는 user group을 만들고, user에 자신의 계정도 새로 만들어서 개발할 때 iam 계정을 통해 사용하도록 한다.( root 계정은 특별한 경우가 아니면 쓰지 않도록 아마존에서도 권장하는듯) 동료 분의 계정을 추가하기 위해 add user을 통해 user이름을 적고 아무 비밀번호를 적거나 auto generated password로 한 후에 required password reset을 체크한다. 다른 방법으로는 access key를 이건 sdk, api를 통해 aws를 사용하는 user를 위한 설정인듯 하니 pass. 
(auto generated password로 설정하면 계정을 만든 후에 welcome email(?)을 보내도록 하는 페이지가 뜰 때 거기에 auto generated password가 있다.)
 
 iam으로 접속할 때 12자리 계정 id가 아닌 별칭을 쓰고 싶다면 iam dashboard에서 오른쪽 사이드바(?)에 별칭 설정이 있다. 그걸 바꿔주면 된다.

Django 개인프로젝트를 진행하면서 AWS ElasticBeanstalk에 배포하는 것을 하던 도중 이런 오류를 만나게 되었는데 일주일 동안 아는 걸 모두 동원해서 고쳐보려해도 고치지 못했습니다. 제가 사용했던 Django 버전은 2.2버전이였고, Ubuntu 16.04, python 3.7을 사용했습니다.

배포할 때는 모두 eb init -> eb create하면 여러가지 옵션들이 나오는데 모두 default값을 사용했습니다.

그러면 현재 2020.06.27 기준 python 3.7를 Amazon Linux2 환경에서 Django 2.2버전을 돌리게 되는 것입니다. 근데 문제는 이런 상태로 deploy를 하면 뭐를 해도 로그에 wsgi에 관련된 에러가 뜨게 됩니다. path를 바꿔봐도 config를 바꿔봐도 해결이 되지 않습니다. 보안, 로드밸런서의 문제도 아닌 것 같습니다.

그래서 해본 것이 Django버전을 2.1로 낮추는 것이였습니다. 그리고 나서 pipfile을 requirements.txt로 바꾸고...등등 근데 그래도 되지 않습니다. 그래서 서버의 버전도 python 3.6에 Amazon Linux로 한 단계 낮추었습니다. 그랬더니 갑자기 아무 문제 없이 돌아갑니다...

결론) 제가 추측을 해보면 python 3.7에 Amazon Linux2에서 Django 2.2버전을 돌리면 어떤 문제가 생기는 것 같습니다. 그래서 그냥 버전을 한 단계씩 낮추어 배포하면 문제 없이 돌아갑니다...