AWS Organizations에서 권한 관리

배경

Organization에 새로운 Account가 추가되면서 새로운 Permission Set과 Group을 만들어야 했다.

기존에는 하나의 Permission Set으로 접근한 뒤 작업용 IAM Role로 AssumeRole하는 방식이었다면, 신규로 들어온 Account는 Permission Set으로 접근해서 바로 작업하는 방식이었다.

여기서 바로 작업한다는 건, 접속한 뒤 별도로 작업용 Role에 AssumeRole하지 않는다는 뜻이다.

그런 와중에 기존 방식과 달랐던 점이 몇 가지 있어 기록으로 남겨두려고 한다.

고객 관리형 정책

AWS Organizations를 통한 계정 관리에서 다뤘던 Permission Set 중, 이번에는 고객 관리형 정책에 대해서 이야기해보려고 한다.

기존에 Organization에 들어와 있던 Account는 Permission Set에 AssumeRole 권한만 있으면 됐다. 해당 권한은 인라인 정책으로 할당하고 있었기 때문에 설정이 그렇게 번거롭지 않았다.

하지만 고객 관리형 정책을 설정하려면 아래와 같은 순서가 필요했다.

1. 해당 Account의 IAM에 먼저 Policy를 만든다.
2. 이후 Permission Set으로 돌아와 고객 관리형 정책에 이름과 경로를 지정한다.
3. Permission Set을 대상 Account의 사용자나 Group에 할당한다. 이미 할당된 Permission Set을 수정했다면 다시 Provisioning한다.

여기서 주의할 점은 Permission Set에 정책을 연결한다고 해당 Account에 Policy가 생기는 것은 아니라는 점이다. Policy가 없으면 에러가 발생하므로, 대상 Account에 먼저 만들어 두어야 한다.

같은 Permission Set을 여러 Account에 사용한다면 각 Account에 같은 이름과 경로의 Policy가 있어야 한다. 고객 관리형 정책 공식 문서

주의 사항

IAM Role에 권한을 직접 추가하려고 하니 에러가 발생했다.

IAM Identity Center가 만드는 AWSReservedSSO_ Role은 IAM 콘솔에서 직접 수정할 수 없다. 권한 변경은 IAM Identity Center의 Permission Set에서 수행한 뒤 대상 Account에 Provisioning해야 한다. Role 수정 제한 공식 문서

다만 당시 Role 이름과 에러 문구는 아직 기록하지 않아, 위 제한 때문에 발생한 것인지는 확인이 필요하다.