MOMIN09Platform & DevOps

AWS Organizations를 통한 계정 관리

6 min read

배경

프로젝트를 진행하며 AWS Organizations와 IAM Identity Center를 통해 여러 AWS 계정의 접근 권한을 관리하고 있었다. 이 구조는 계정, 그룹, 사용자 접근의 진입점 역할을 하므로, 운영 중 확인한 내용을 기록해 둔다.

AWS Organizations란

AWS Organizations는 여러 AWS 계정을 하나의 조직 단위로 묶어 중앙에서 관리할 수 있게 해주는 서비스이다. 관리 계정에서 멤버 계정을 생성하거나 초대할 수 있고, OU(Organizational Unit)로 계정을 그룹화해 정책과 거버넌스를 일관되게 적용할 수 있다. 특히 IAM Identity Center와 함께 사용하면 여러 계정에 대한 사용자 접근 권한을 중앙에서 관리하는 진입점 역할을 한다.

IAM Identity Center

User / Group

IAM Identity Center에는 사용자와 그룹을 등록할 수 있다. 단일 AWS 계정의 IAM User/Group과 유사한 개념이지만, 여러 계정 접근을 중앙에서 관리하기 위한 사용자/그룹이라고 보면 된다.

Permission Set

사용자가 각 AWS 계정 콘솔에 접근할 때 부여받는 권한 묶음이다. Permission Set에는 다음과 같은 형태의 권한을 연결할 수 있다.

  • AWS 관리형 정책
  • 고객 관리형 정책
  • 인라인 정책
  • 권한 경계

현재 프로젝트에서는 권한 경계를 사용하고 있지 않아, 정확한 동작 방식은 추가로 학습이 필요하다.

Permission Set은 생성만으로는 실제 계정에서 사용할 수 없다. 아래의 Provisioning 과정을 통해 대상 계정에 반영되어야 실질적으로 사용할 수 있다.

Provisioning

AWS Organizations에 포함된 계정과 Permission Set을 연결하는 작업이다. Provisioning이 완료되면 AWS access portal에서 사용자에게 할당된 계정과 Permission Set을 확인할 수 있다.

여기까지는 일반적인 과정이고, 아래에서는 Provisioning 단계에서 실제로 어떤 일이 일어나는지 정리한다.

Provision

관리 계정 또는 IAM Identity Center의 관리 주체가 조직의 멤버 계정에 Permission Set을 반영하는 과정에서는 어떤 일이 일어날까?

우선 앞서 말한 것처럼 Permission Set과 계정을 연결한다. 이때 대상은 관리 계정이 아니라 조직에 속한 멤버 계정이다.

Provisioning이 완료되면 대상 계정에 IAM Role이 생성되어 있는 것을 확인할 수 있다. Role 이름은 다음 형식을 따른다.

AWSReservedSSO_[PERMISSION_SET_NAME]_[HASH_VALUE]

사용자는 Provisioning된 Permission Set을 통해 해당 Role로 AssumeRole 하게 된다.

해당 Role의 특징은 다음과 같다.

  • 임의로 trust relationship을 수정할 수 없다.
  • 멤버 계정에서 직접 권한을 부여하는 방식으로 관리하지 않는다.

이는 중앙 통제를 위해 IAM Identity Center에서 관리되는 구조로 볼 수 있다.

그렇기 때문에 추가 권한이 필요하다면 대상 계정의 Role을 직접 수정하는 것이 아니라 Permission Set에 권한을 부여해야 한다.

AWS 관리형 정책이 아닌 고객 관리형 정책이 필요하다면, 사전에 대상 계정에 동일한 이름과 경로의 policy를 만들어 두어야 Identity Center에서 해당 policy를 연결할 수 있다.

CLI를 사용하려면?

AWS access portal에서 임시 access key, secret access key, session token을 확인할 수 있다. 하지만 매번 직접 복사해 credentials 파일을 수정해야 해서 번거롭다.

SSO를 이용해 접근하는 구조이므로 credentials 파일을 직접 수정하지 않고 AWS config 파일에 SSO profile을 설정해서 사용할 수 있다. 예시는 다음과 같다.

1. default profile

# config
[default]
sso_start_url = https://[DOMAIN].awsapps.com/start
sso_region = [SSO_REGION]
sso_registration_scopes = sso:account:access
sso_role_name = [PERMISSION_SET_NAME]
sso_account_id = [PROVISIONED_ACCOUNT_ID]
region = [REGION]
output = [OUTPUT]
aws sso login

2. custom profile

# config
[sso-session [SESSION_NAME]]
sso_start_url = https://[DOMAIN].awsapps.com/start
sso_region = [SSO_REGION]
sso_registration_scopes = sso:account:access
 
[profile sso-role]
sso_session = [SESSION_NAME]
sso_role_name = [PERMISSION_SET_NAME]
sso_account_id = [PROVISIONED_ACCOUNT_ID]
region = [REGION]
output = [OUTPUT]

default profile이 아니므로 아래처럼 profile을 지정해 로그인해야 한다.

aws sso login --profile sso-role

3. 실사용 profile 예시

SSO profile을 진입점으로 사용하고, 그 profile에서 다른 계정의 Role로 AssumeRole 하는 경우 source_profile을 추가해 사용한다.

# config
[sso-session [SESSION_NAME]]
sso_start_url = https://[DOMAIN].awsapps.com/start
sso_region = [SSO_REGION]
sso_registration_scopes = sso:account:access
 
[profile sso-role]
sso_session = [SESSION_NAME]
sso_role_name = [PERMISSION_SET_NAME]
sso_account_id = [PROVISIONED_ACCOUNT_ID]
region = [REGION]
output = [OUTPUT]
 
[profile sso-dev]
role_arn = [DEV_ACCOUNT_ROLE_ARN]
role_session_name = [DEV_SESSION_NAME]
region = [REGION]
output = [OUTPUT]
source_profile = sso-role
 
[profile sso-stg]
role_arn = [STG_ACCOUNT_ROLE_ARN]
role_session_name = [STG_SESSION_NAME]
region = [REGION]
output = [OUTPUT]
source_profile = sso-role

이후 CLI 사용은 다음과 같다.

aws sso login --profile sso-role # 반드시 선행되어야 함
aws [RESOURCE_TYPE] [ACTION] --profile sso-dev
aws [RESOURCE_TYPE] [ACTION] --profile sso-stg

그래프 뷰