GCP IAM 알아보기 - Principal, Role, Policy, Service Account
앞선 리소스 계층 글에서 Organization -> Folder -> Project로 이어지는 리소스 계층과, 권한/정책이 위에서 아래로 상속된다는 점을 알아보았습니다. 이번에는 그 권한 체계의 핵심인 GCP IAM(Identity and Access Management)에 대해 알아보겠습니다. GCP IAM은 결국 “누가(Principal) 무엇을(Role) 어디에(Resource) 할 수 있는가” 를 정의하는 체계입니다. 이 세 가지와 그것을 묶는 정책(Policy)의 구조만 이해하면, 콘솔이든 gcloud든 Terraform이든 권한 설정이 한결 수월해집니다. 이번 글에서는 IAM의 핵심 구성요소와 Service Account, 그리고 gcloud로 권한을 부여하는 실습까지 정리합니다.
TL;DR
- IAM은 Principal(누가) + Role(무엇을) -> Resource(어디에) 를 binding으로 묶어 권한을 부여합니다.
- 권한(permission)은 직접 줄 수 없고, 항상 Role(권한의 묶음) 단위로 부여합니다.
- Role은 Basic(Owner/Editor/Viewer) / Predefined / Custom 세 종류이며, 실무에서는 Predefined를 우선합니다.
- Allow Policy는 리소스에 붙고 상위에서 하위로 상속되며, 유효 권한은 모든 상위 정책의 합집합(Union) 입니다.
- Service Account는 사람이 아닌 워크로드의 신원이며, 키 파일보다 keyless(Workload Identity Federation 등) 가 권장됩니다.
1. IAM 한눈에 보기
GCP IAM은 세 가지 요소와, 그 둘을 묶는 한 가지 연결로 이루어집니다.
| 요소 | 의미 | 예시 |
|---|---|---|
| Principal | 누가 (신원) | 사용자, 그룹, Service Account |
| Role | 무엇을 (권한의 묶음) | roles/viewer, roles/storage.objectAdmin |
| Resource | 어디에 (대상) | Project, GCS 버킷, GCE 인스턴스 |
| Binding | Principal + Role 묶음 | “alice 에게 이 Project의 Viewer” |
핵심 규칙은 권한(permission)을 Principal에게 직접 줄 수 없다는 점입니다. 항상 permission의 묶음인 Role을 Principal에게 부여(binding)하고, 그 binding의 집합이 리소스에 붙는 Allow Policy가 됩니다.
2. Principal - 누가 (신원)
Principal(예전 명칭 member)은 인증된 신원을 의미하며, 크게 사람과 워크로드로 나뉩니다.
| 종류 | 식별자 예시 | 설명 |
|---|---|---|
| Google 계정 (user) | user:alice@example.com | 개인 사용자 |
| Google 그룹 (group) | group:dev-team@example.com | 사용자 묶음, 권한 관리의 기본 단위 |
| Service Account | serviceAccount:app-sa@PROJECT.iam.gserviceaccount.com | 워크로드(앱)의 신원 |
| 도메인 (domain) | domain:example.com | Workspace/Cloud Identity 전체 |
| 전체 인증 사용자 | allAuthenticatedUsers | 로그인된 모든 Google 계정 |
| 전체 (allUsers) | allUsers | 익명 포함 인터넷 전체 (주의) |
개별 사용자에게 일일이 권한을 주기보다, Google 그룹에 Role을 부여하고 사람을 그룹에 넣고 빼는 방식이 관리/감사 측면에서 훨씬 안전합니다.
3. Role - 무엇을 (권한의 묶음)
Role은 여러 permission(service.resource.verb 형식, 예: storage.objects.get)을 묶은 단위입니다. Role은 세 종류가 있습니다.
| Role 종류 | 설명 | 사용 권장 |
|---|---|---|
| Basic | Owner / Editor / Viewer. 광범위한 권한 | 테스트/학습용. 운영 지양 |
| Predefined | Google이 서비스별로 관리하는 세분화된 Role | 실무 1순위 |
| Custom | 필요한 permission만 직접 골라 만든 Role | Predefined로 부족할 때 |
Basic Role(특히 Owner, Editor)은 권한 범위가 너무 넓어 최소 권한 원칙에 어긋납니다. 예를 들어 GCS 객체 읽기만 필요하면 roles/storage.objectViewer 같은 Predefined Role을 쓰는 것이 맞습니다.
Basic Role은 “일단 되게 하려고” 부여하기 쉽지만, 운영 환경에서는 사고의 폭발 반경(blast radius)을 키웁니다. Predefined -> (부족하면) Custom 순서로 좁혀가세요.
4. Allow Policy와 상속
Allow Policy는 “어떤 Principal이 어떤 Role을 가지는가”를 정의한 binding의 집합으로, 리소스(Project, 버킷 등)에 부착됩니다. 구조를 단순화하면 다음과 같습니다.
1
2
3
4
5
6
7
8
9
# 리소스에 붙는 Allow Policy (개념 예시)
bindings:
- role: roles/viewer
members:
- user:alice@example.com
- group:dev-team@example.com
- role: roles/storage.objectAdmin
members:
- serviceAccount:app-sa@my-project.iam.gserviceaccount.com
리소스 계층 글에서 봤듯이, 상위 노드(Organization/Folder/Project)에 부여한 정책은 하위로 상속되고, 특정 리소스에 실제 적용되는 권한은 자기 정책 + 모든 상위 정책의 합집합(Union) 인 Effective Allow Policy입니다.
IAM에는 allow policy 외에 Deny Policy, IAM Conditions(조건부 바인딩), Principal Access Boundary 등 더 정교한 제어 수단도 있습니다. 입문 단계에서는 “allow + 상속(union)”을 먼저 확실히 잡고, 차단이 필요할 때 Deny/Condition을 찾아보면 됩니다.
5. Service Account - 워크로드의 신원
Service Account(SA) 는 사람이 아니라 애플리케이션이나 워크로드(GCE 인스턴스, GKE Pod 등)가 사용하는 특수한 신원입니다. 비밀번호가 없고, 키 또는 단기 토큰으로 인증한다는 점이 일반 사용자 계정과 다릅니다.
Service Account는 두 가지 성격을 동시에 가집니다.
- Principal로서: 다른 리소스에 대한 Role을 부여받습니다 (예: 버킷에
roles/storage.objectViewer). - Resource로서: 다른 Principal이 이 SA에 대한 권한을 부여받습니다 (예: 개발자가 SA에
roles/iam.serviceAccountUser).
5.1. 인증 방식 - 키 파일보다 keyless
SA 인증에서 가장 중요한 보안 포인트는 키 파일(JSON)을 가능하면 쓰지 않는 것입니다. 키 파일은 장기 자격증명이라 유출 시 위험이 크고 회전(rotation) 관리 부담도 큽니다.
| 방식 | 자격증명 | 권장도 |
|---|---|---|
| Attached Service Account | 메타데이터 단기 토큰 | GCE/GKE 등 GCP 내부 워크로드 1순위 |
| Workload Identity Federation | 외부 IdP 토큰 교환 | GitHub Actions 등 외부 워크로드 |
| Service Account Impersonation | 단기 토큰 | 사람이 임시로 SA 권한 사용 |
| Service Account Key (JSON) | 장기 키 파일 | 최후의 수단, 유출 위험 |
기본 생성되는 Default Service Account는 권한이 넓게 설정되는 경우가 많습니다. 그대로 쓰지 말고, 워크로드마다 최소 권한 전용 SA를 만들어 붙이는 것이 안전합니다.
6. gcloud로 IAM 다뤄보기
개념을 정리했으니 gcloud로 직접 권한을 부여해 보겠습니다. 아래 예시는 이전 글에서 만든 my-first-project-461203 Project 기준입니다.
6.1. 사용자에게 Role 부여 / 회수
1
2
3
4
5
6
7
8
9
10
# 사용자에게 Project 레벨 Viewer 부여 (binding 추가)
❯ gcloud projects add-iam-policy-binding my-first-project-461203 \
--member="user:alice@example.com" \
--role="roles/viewer"
Updated IAM policy for project [my-first-project-461203].
# 부여한 binding 회수
❯ gcloud projects remove-iam-policy-binding my-first-project-461203 \
--member="user:alice@example.com" \
--role="roles/viewer"
6.2. 현재 정책(바인딩) 확인
1
2
3
4
5
❯ gcloud projects get-iam-policy my-first-project-461203 \
--format="table(bindings.role, bindings.members)"
ROLE MEMBERS
roles/owner ['user:me@example.com']
roles/viewer ['user:alice@example.com']
6.3. Service Account 생성과 권한 부여
1
2
3
4
5
6
7
8
9
# 1) Service Account 생성
❯ gcloud iam service-accounts create app-sa \
--display-name="App Service Account"
Created service account [app-sa].
# 2) SA에 최소 권한 Role 부여 (GCS 객체 읽기 전용)
❯ gcloud projects add-iam-policy-binding my-first-project-461203 \
--member="serviceAccount:app-sa@my-first-project-461203.iam.gserviceaccount.com" \
--role="roles/storage.objectViewer"
6.4. 로컬/CI 인증 - ADC
로컬 개발이나 CI에서 SDK가 자격증명을 찾는 표준 방식이 ADC(Application Default Credentials) 입니다. 키 파일 없이 본인 계정으로 로그인해 ADC를 설정할 수 있습니다.
1
2
3
4
5
6
# 키 파일 없이 ADC 설정 (로컬 개발용)
❯ gcloud auth application-default login
# (지양) SA 키 파일 발급 - 유출 위험, 가능하면 keyless 사용
❯ gcloud iam service-accounts keys create key.json \
--iam-account=app-sa@my-first-project-461203.iam.gserviceaccount.com
7. 주의사항 및 팁
7.1. 최소 권한과 Role 선택 순서
Owner/Editor 같은 Basic Role을 습관적으로 부여하지 말고, Predefined -> (부족하면) Custom 순서로 필요한 만큼만 부여합니다. 권한은 상속되어 합쳐지므로, 상위 노드에 넓은 권한을 주면 하위 전체에 퍼진다는 점을 늘 염두에 둬야 합니다.
7.2. 개인보다 그룹
사람마다 직접 binding하면 입퇴사/이동 때마다 정책이 흐트러집니다. Google 그룹에 Role을 부여하고 멤버십으로 관리하면 정책은 그대로 두고 사람만 넣고 뺄 수 있습니다.
7.3. SA 키 파일은 마지막 수단
SA 키(JSON)는 장기 자격증명이라 유출 시 회수가 어렵습니다. GCP 내부 워크로드는 Attached Service Account, 외부 워크로드(예: GitHub Actions)는 Workload Identity Federation을 우선 검토하세요.
8. 참고: AWS IAM 대응
AWS IAM에 익숙하다면 아래 대응표가 도움이 됩니다. 개념이 1:1로 맞지는 않으니 대략적인 매핑으로만 참고하세요.
| GCP | AWS | 비고 |
|---|---|---|
| Principal (user/group/SA) | IAM User / Group / Role, 페더레이션 ID | GCP는 권한을 리소스에 부착+상속 |
| Role (permission의 묶음) | IAM Policy (managed/inline) | GCP Role = 권한 묶음, AWS Policy = 권한 문서 |
| Predefined Role | AWS managed policy | 둘 다 벤더 관리 |
| Allow Policy / Binding | identity/resource에 attach된 Policy | GCP는 계층 상속, AWS는 주로 identity 부착 |
| Service Account | 워크로드용 IAM Role | GCP SA는 신원이자 resource |
| Workload Identity Federation | IAM Roles Anywhere / OIDC federation | 둘 다 keyless 외부 인증 |
| Service Account Key | IAM access key (장기 자격증명) | 둘 다 회피 권장 |
가장 큰 차이는 권한이 리소스 계층을 따라 상속(union) 된다는 점, 그리고 GCP의 Role이 곧 permission의 묶음이라는 점입니다.
9. Reference
- Google Cloud Docs - IAM overview
- Google Cloud Docs - Understanding roles
- Google Cloud Docs - Service accounts overview
- Google Cloud Docs - Workload Identity Federation
- Google Cloud Docs - Application Default Credentials
- Google Cloud Docs - Manage access to projects, folders, and organizations
궁금하신 점이나 추가해야 할 부분은 댓글이나 아래의 링크를 통해 문의해주세요.
Written with KKamJi