[Tech]서비스 계정을 가장(impersonation)하여 임시 권한을 획득하기

서비스 계정 가장(impersonation)이란?

사용자 또는 다른 서비스 계정과 같은 인증된 주 구성원이 서비스 계정의 권한을 얻기 위해 서비스 계정으로 인증될 때 이를 서비스 계정을 가장한다고 부릅니다. 서비스 계정을 가장하면 서비스 계정이 액세스할 수 있는 무엇이든 인증된 주 구성원이 액세스할 수 있습니다. 적절한 권한을 사용해서 인증된 주 구성원만 서비스 계정을 가장할 수 있습니다.

가장은 Identity and Access Management(IAM) 정책을 변경하지 않고 사용자 권한을 변경하려고 할 때 유용합니다. 예를 들어 가장을 사용하면 사용자에게 승격된 액세스 권한을 일시적으로 부여하거나 어떤 태스크에 대해 특정 권한 집합이 충분한지 여부를 테스트해볼 수 있습니다. 또한 가장을 사용해서 서비스 계정으로만 실행 가능한 애플리케이션을 로컬로 개발하거나 Google Cloud 외부에서 실행되는 애플리케이션을 인증할 수도 있습니다.


사용 범위

서비스 계정 가장(impersonation)이 가능한 범위

  • 동일한 프로젝트
  • 동일한 조직의 다른 프로젝트
  • 다른 조직의 다른 프로젝트

동일한 프로젝트뿐만 아니라 다른 조직의 다른 프로젝트 내 서비스 계정 또한 가장(impersonation)이 가능합니다.


사용 사례

일반적으로는 IAM 정책을 변경하지 않고 사용자 권한을 변경하고자 할 때 유용하게 사용할 수 있습니다.

  • 사용자에게 임시로 승격된 액세스 부여
  • 특정 태스크에 대해 특정 권한 집합이 충분한지 여부 테스트
  • 서비스 계정으로만 실행될 수 있는 애플리케이션 로컬 개발
  • 외부 애플리케이션 인증

※ Google Cloud 서비스 계정 가장(impersonation)은 AssumeRole과 같은 AWS 보안 토큰 서비스 API 메서드와 비슷합니다.


작동 방식

서비스 계정을 가장(impersonation)하기 위해 인증된 주 구성원은 서비스 계정에 대한 토큰을 가져온 후 이 토큰을 사용해서 서비스 계정으로 인증을 수행합니다.


서비스 계정을 가장(impersonation)하게 되면 직접적으로 서비스 계정 키를 사용하지 않을 수 있어 보안 측면에서 더 안전한 방법으로 꼽힙니다.

또한 주 구성원이 서비스 계정을 가장(impersonation)하는 동안 리소스에 액세스하면 대부분의 감사 로그에는 ID와 가장(impersonation)하려는 서비스 계정 ID가 모두 포함됩니다.


※ Google Cloud 콘솔을 사용할 때는 항상 사용자 인증 정보를 사용해서 인증을 수행합니다. 그렇기 때문에 Google Cloud 콘솔에서는 서비스 계정을 가장(impersonation)하여 리소스에 액세스할 수 없습니다.


필수 권한

서비스 계정을 가장(impersonation)하려면 iam.serviceAccounts.getAccessToken 권한이 필요합니다.

이 권한은 “서비스 계정 토큰 생성자” 역할(roles/iam.serviceAccountTokenCreator)과 같은 역할에 포함됩니다.


참고로 프로젝트 수준에서 가장(impersonation)하려는 주 구성원에 대한 “서비스 계정 토큰 생성자” 역할을 부여하게 된다면, 해당 프로젝트 내의 모든 서비스 계정에 대한 가장(impersonation)이 가능하게 됩니다.

특정 서비스 계정에 대한 가장(impersonation)만을 허용하고 싶다면 프로젝트 수준에서 역할을 부여하는 것이 아닌, 가장(impersonation)할 서비스 계정에 대해서만 역할을 부여하면 됩니다.


  • 타겟 : dohyeon-target@PROJECT_ID.iam.gserviceaccount.com
  • 소스 : dohyeon-source-a@PROJECT_ID.iam.gserviceaccount.com,
          dohyeon-source-b@PROJECT_ID.iam.gserviceaccount.com


여기서 소스는 타겟이 가장(impersonation)하고자 하는 서비스 계정을 뜻합니다. 각 소스 서비스 계정은 프로젝트 수준에서 “저장소 관리자” 역할을 가지고 있습니다.

※ 소스 서비스 계정에는 테스트해 보고자 하는 역할을 부여하셔도 됩니다. 해당 글에서는 Cloud Storage 버킷 리스트를 조회하고자 “저장소 관리자” 역할을 부여했습니다.

타겟은 소스 서비스 계정을 가장(impersonation)하여 소스의 역할 및 권한을 임시로 획득하려는 서비스 계정을 뜻합니다. 타겟 서비스 계정은 프로젝트 수준에서는 아무 역할 및 권한을 부여하지 않았으며, 소스 서비스 계정 중 하나인 dohyeon-source-a@PROJECT_ID.iam.gserviceaccount.com에 대해서만 “서비스 계정 토큰 생성자” 역할을 가지고 있습니다.


위 내용대로 서비스 계정을 생성해 보도록 하겠습니다.

  • 접근 경로 : IAM 및 관리자 > 서비스 계정 > 서비스 계정 만들기 클릭
  1. 서비스 계정 이름을 기입(서비스 계정 ID 필드가 자동으로 채워짐)
  2. 완료 버튼 클릭


위 프로세스와 동일하게 진행하여 소스 서비스 계정 2개도 생성해 줍니다.


이후 각 소스 서비스 계정들에 “저장소 관리자” 역할을 부여하겠습니다.

  • 접근 경로 : IAM 및 관리자 > IAM > 액세스 권한 부여 클릭

  1. 새 주 구성원 필드에 소스 서비스 계정들을 기입
  2. 역할에 “저장소 관리자” 지정
  3. 저장 버튼 클릭


IAM 콘솔에서 서비스 계정들을 확인합니다.

소스 서비스 계정들은 모두 저장소 관리자 역할이 할당되어 있는 것을 확인할 수 있으며, 타겟 서비스 계정에는 아무 역할도 할당하지 않았기 때문에 해당 목록에서 표시되지 않는 것을 확인할 수 있습니다.


소스 서비스 계정 중 source-a 계정에만 타겟 서비스 계정에 대한 “서비스 계정 토큰 생성자” 역할을 부여하겠습니다.

  • 접근 경로 : IAM 및 관리자 > 서비스 계정 > 소스 서비스 계정 클릭 > 권한 탭 > 액세스 권한 부여 클릭

  1. 새 주 구성원 필드에 타겟 서비스 계정 기입
  2. 역할에 “서비스 계정 토큰 생성자” 지정
  3. 저장 버튼 클릭


현재까지의 과정을 정리해 보면 타겟 서비스 계정은 source-a 서비스 계정에 대해서만 “서비스 계정 토큰 생성자” 역할을 부여받아 source-a 서비스 계정에 대해서만 가장(impersonation)을 할 수 있고, source-b 서비스 계정에 대해서는 가장(impersonation)을 할 수 없습니다.


gcloud cli를 이용해도 되지만 해당 글에서는 Cloud Shell을 통해 진행하겠습니다.

1. 타겟 서비스 계정으로 로그인하기 위해 타겟 서비스 계정의 키를 생성합니다.

gcloud iam service-accounts keys create KEY_FILE \

--iam-account=TARGET_SA_NAME@PROJECT_ID.iam.gserviceaccount.com


2. 생성된 키를 통해 타겟 서비스 계정으로 로그인합니다.

gcloud auth login --cred-file=KEY_FILE


3. 현재 로그인 중인 계정을 확인하려면 아래 명령어로 확인합니다.

gcloud auth list


4. 현재 활성화되어 있는 타겟 서비스 계정으로 Cloud Storage 버킷 목록을 조회해 봅니다.

gcloud storage buckets list

권한이 없어 버킷 목록 조회가 불가능한 상태입니다.


5. source-a 서비스 계정을 가장(impersonation)하여 버킷 목록을 조회해 보겠습니다.
서비스 계정을 가장(impersonation)하기 위해 --impersonate-service-account 플래그를 사용합니다.  

gcloud storage buckets list --impersonate-service-account=SOURCE_SA_NAME

“저장소 관리자” 역할이 할당되어 있는 source-a 서비스 계정을 가장(impersonation)해 버킷 목록 조회가 가능한 내용을 확인할 수 있습니다.


6. source-b 서비스 계정도 가장(impersonation)이 가능한지 확인해 봅니다.

타겟 서비스 계정은 source-b 서비스 계정에 대해 “서비스 계정 토큰 생성자” 역할이 없기 때문에 source-b 서비스 계정으로 가장(impersonation)이 불가능한 것을 확인할 수 있습니다.


이처럼 특정 서비스 계정에 대해서만 “서비스 계정 토큰 생성자” 역할을 부여하게 된다면 해당 서비스 계정으로의 가장(impersonation)만 할 수 있는 점을 확인했습니다.

만일 타겟 서비스 계정을 프로젝트 수준에서 “서비스 계정 토큰 생성자” 역할을 부여하게 된다면 해당 프로젝트 내의 모든 서비스 계정을 가장(impersonation)할 수 있습니다.

소스 서비스 계정의 키를 관리하지 않아도 된다는 점에 있어서 다양한 환경에서 유용하게 적용할 수 있을 것으로 보입니다.


🔗 참고 링크

- 서비스 계정 가장(impersonation)

- 서비스 계정 키 만들기

- 서비스 계정 키를 사용하여 서비스 계정 승인

- 특정 gcloud CLI 명령어에 가장(impersonation) 사용



-Technical Engineering Team 이도현






클라우드메이트 IAM 서비스는 계정, 그룹, 역할, 권한, 시크릿 등을 토대로 멀티 클라우드 환경에서 안전한 권한 생성과 부여 작업을 지원합니다. 호환 걱정 없이 멀티 클라우드 환경에서 IAM 체계를 구축하길 원하시는 분, 클라우드메이트의 다양한 자체 개발 제품들을 사용하기 원하시는 분이라면 아래의 링크를 확인해보세요!

보안을 위한 계정관리 SaaS 'IAM' 바로가기