회사에서 단일 aws 계정으로 모든 리소스를 관리하고 있었다. 그런데 권한 제어가 제대로 설정되어 있지 않아서, 리소스 관리가 제대로 되지 않고 있었다. 가령 어떤 리소스가 testbed 로 생성되었는지 어떤 리소스가 production 용인지 추적이 제대로 안되었다.
이 때문에 Aws iam 계정에 대한 권한 제어를 세분화 하였는데, 이렇게 되니 개발자들이 새로운 aws 서비스에 대한 기술 검증을 시도해보는 것이 번거로워졌다.
이 문제를 해결하기 위해 Aws iam 계정에 대한 권한을 다 부여하고 리소스 생성 시 태그를 붙이도록 안내하고 Aws config, CloudTrail 을 통해 추적하는 방법도 있지만, 권한을 전부 허용하는 것은 production 워크로드가 있는 계정에서 너무 리스크가 큰 방법이라고 생각했다.
그래서 aws IAM Role의 기능을 활용하여 개발자들이 단일 IAM 계정을 통해 격리된 Sandbox 계정 에서 자유롭게 aws 서비스에 대한 기술검증 및 실험을 할 수 있도록 설계하였다. 오늘 포스트에서는 해당 내용에 대해 다룰 것이다.
새로운 Aws root 계정(sandbox 계정)을 생성한다. 그리고 해당 root 계정을 기존에 있던 aws root 계정이 소속된 organization 에 추가한다. (이는 회사에서 비용을 계산할 때 계정 별로 보기 위함이다.)
Role 생성 시 신뢰할 수 있는 엔터티 유형으로 aws 계정을 선택하고 다른 aws 계정의 계정 ID 입력 란에 원래 사용하고 있던 aws root 계정의 id 를 입력한다. 이렇게 하면 나중에 개발자들이 원래 사용하고 있던 aws root 계정에 속한 iam 계정으로 sandbox 계정의 Role 에 접근할 수 있다.
[권한 추가]
정책은 따로 만들어도 되고, 기존에 있는 정책을 사용해도 된다. 우리의 경우 개발자들의 자유도를 위해 사전 정의된 정책인 AdministratorAccess 에서 몇 가지 크리티컬한 권한을 제외하도록 정책을 설정하였다.
역할 이름을 지정하고 생성한 후 역할의 이름을 복사한다.
원래 root 계정의 iam 계정으로 로그인 한 후 역할 전환 버튼을 클릭한다.
Account id 에 처음 만든 sandbox 계정의 id 를 입력하고 IAM Role 이름을 입력한다. 그 다음 Switch Role 을 하면 다른 iam 계정의 credential로 로그인하여도 Role 을 통해 sandbox 계정 환경에 접근할 수 있다.
역할을 전환하면, 원래 계정에 있었던 리소스가 하나도 안보이는 것을 알 수 있다. 즉 Sandbox 계정에 접근하게 된 것이다. 이제 개발자들이 Sandbox 계정을 통해 production 계정과 격리된 환경에서 자유롭게 aws 리소스 들을 생성하고 실험할 수 있게 되었다.