GCP IAM 기본 개념: Role, Principal, Policy 이해하기

GCP IAM은 "누가(Principal) 무엇을(Role) 어디에(Resource) 할 수 있는가"를 allow policy로 묶어 권한을 부여합니다. 이 세 가지를 분리해서 이해하면 권한 설계가 단순해집니다.

핵심 요약

• GCP IAM의 권한 부여는 Principal에게 Resource에 대한 Role을 grant하는 한 문장으로 요약됩니다.
• Principal은 권한을 받는 주체(사용자, 서비스 계정, 그룹 등)입니다.
• Role은 권한(Permission)의 묶음이며, Permission은 service.resource.verb 형식입니다.
• Allow Policy는 "어떤 Principal에게 어떤 Role을 부여하는가"를 정의한 binding의 모음이고, Resource에 붙습니다.
• Permission은 Principal에게 직접 줄 수 없습니다. 반드시 Role을 통해서만 부여됩니다.
• 상위 리소스(조직/폴더/프로젝트)에 부여한 권한은 하위 리소스로 상속됩니다.

1. 왜 이 개념이 필요한가

GCP를 처음 다룰 때 가장 흔한 실수는 이렇습니다. 팀원에게 Cloud Storage 버킷 하나만 보게 하려다가, IAM 화면에서 익숙한 "Editor"를 골라 프로젝트 전체 편집 권한을 줘버리는 경우입니다.

이 한 번의 클릭으로 그 팀원은 버킷뿐 아니라 Compute 인스턴스 삭제, 네트워크 변경, 다른 버킷 접근까지 할 수 있게 됩니다. 권한을 "사람"에 막연히 붙이는 방식으로 생각하면 이런 사고가 반복됩니다.

GCP IAM은 권한을 세 가지 축으로 나눠서 생각하도록 설계되어 있습니다.

• 누구에게 권한을 줄 것인가 → Principal
• 무엇을 할 수 있게 할 것인가 → Role
• 어디에 대해 허용할 것인가 → Resource

이 세 축을 분리해서 보면, 위 사례는 "이 사용자(Principal)에게 / 객체 조회 권한(Role)을 / 이 버킷(Resource)에만" 부여하는 문제로 정리됩니다. 프로젝트 전체가 아니라 버킷 하나로 범위가 좁혀집니다.

2. 한 줄 정의

GCP IAM은 Principal에게 특정 Resource에 대한 Role을 allow policy로 부여하여 접근을 제어하는 서비스입니다.

Google Cloud 공식 문서는 권한 부여를 다음 한 문장으로 설명합니다. "Principal에게 Resource에 대한 Role을 grant한다." 이 문장의 각 단어가 곧 IAM의 핵심 구성 요소입니다.

3. 핵심 구성 요소

gcp-iam-core-concepts

3.1 Principal (주체)

Principal은 권한을 받는 신원(identity)입니다. 과거 문서에서 "member"라고 부르던 것과 같은 개념이며, 현재는 principal로 통일되었습니다.

Principal 종류	설명	예시
Google 계정	개인 사용자	alice@example.com
서비스 계정	애플리케이션/워크로드용 신원	app@project.iam.gserviceaccount.com
Google 그룹	여러 사용자 묶음	dev-team@example.com
Google Workspace / Cloud Identity 도메인	도메인 전체	example.com

실무에서 사람에게는 그룹 단위로, 애플리케이션에는 서비스 계정으로 권한을 부여하는 것이 관리 측면에서 유리합니다. 사람 한 명씩 직접 부여하면 인원 변동 시마다 수정해야 합니다.

3.2 Permission과 Role

Permission은 "특정 작업을 수행할 수 있는 권한" 하나하나를 의미하며, service.resource.verb 형식을 따릅니다.

compute.instances.list     # Compute 인스턴스 목록 조회
storage.objects.get        # Storage 객체 읽기
resourcemanager.projects.get  # 프로젝트 정보 조회

중요한 제약이 하나 있습니다. Permission은 Principal에게 직접 부여할 수 없습니다. 항상 Role이라는 묶음을 통해서만 부여됩니다. Role은 관련된 Permission들을 모아놓은 named collection입니다.

3.3 Resource (대상)

Resource는 권한이 적용되는 대상입니다. Compute 인스턴스, Cloud Storage 버킷 같은 개별 리소스일 수도 있고, 프로젝트·폴더·조직 같은 컨테이너일 수도 있습니다.

allow policy는 이 Resource에 직접 붙습니다. 그래서 "어디에" 권한을 주는지가 Resource 단위로 결정됩니다.

4. Role의 세 가지 종류

gcp-iam-role-types

Role은 어떻게 만들어졌는지에 따라 세 가지로 나뉩니다. 운영 환경에서 어떤 것을 선택할지는 보안과 관리 편의성의 trade-off로 결정됩니다.

종류	설명	Permission 범위	권장 상황
Basic Role	Owner, Editor, Viewer (구 primitive role)	모든 서비스에 걸친 광범위한 권한	권장하지 않음 (불가피한 경우만)
Predefined Role	GCP가 서비스별로 제공	작업 단위로 한정	대부분의 경우 우선 검토
Custom Role	사용자가 Permission을 직접 조합	필요한 Permission만	predefined로 부족할 때

4.1 Basic Role을 운영에서 피하는 이유

Basic Role(Owner/Editor/Viewer)은 모든 Google Cloud 서비스에 걸쳐 수천 개의 Permission을 포함합니다. AWS의 AdministratorAccess를 떠올리면 됩니다. 시작은 편하지만, 최소 권한 원칙과 정면으로 충돌합니다.

Google Cloud 보안 가이드는 운영 환경에서 대안이 없는 경우가 아니라면 basic role을 부여하지 말 것을 권장합니다. 대신 가장 제한적인 predefined role이나 custom role을 사용하도록 안내합니다.

4.2 Predefined Role 우선, 부족하면 Custom Role

실무 기본값은 predefined role입니다. 예를 들어 객체만 읽으면 되는 경우 roles/storage.objectViewer가 적합합니다. predefined role로 표현되지 않는 권한 조합이 필요할 때만 custom role을 직접 정의합니다.

Tip
custom role은 유연하지만 직접 관리해야 하는 부담이 있습니다. 새 API가 추가되어도 자동으로 Permission이 갱신되지 않습니다. predefined role로 충분하다면 우선 사용하고, custom role은 꼭 필요한 범위로 좁혀서 만드는 것이 운영에 유리합니다.

5. Allow Policy와 Role Binding

gcp-iam-allow-policy

세 가지 구성 요소를 실제로 묶는 것이 allow policy입니다.

5.1 구조

Allow policy는 role binding들의 모음입니다. 하나의 role binding은 다음을 연결합니다.

• 하나 이상의 Principal
• 단일 Role
• (선택) 적용 조건을 정의하는 Condition

JSON으로 보면 다음과 같습니다.

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:alice@example.com",
        "group:dev-team@example.com"
      ]
    },
    {
      "role": "roles/compute.instanceAdmin.v1",
      "members": [
        "serviceAccount:app@my-project.iam.gserviceaccount.com"
      ]
    }
  ]
}

이 policy를 특정 버킷이나 프로젝트에 붙이면, 해당 Resource에 대해 binding이 적용됩니다.

5.2 IAM Condition

binding에 condition을 추가하면 "특정 조건일 때만" 권한이 적용되도록 제한할 수 있습니다. 예를 들어 특정 시간대에만, 또는 이름이 특정 prefix로 시작하는 리소스에만 권한을 주는 식입니다. 조건부 접근으로 권한 범위를 더 좁힐 수 있습니다.

6. 리소스 계층과 권한 상속

gcp-iam-resource-hierarchy

GCP IAM을 이해할 때 가장 자주 놓치는 부분이 상속입니다. GCP 리소스는 계층 구조를 가집니다.

Organization
  └─ Folder
       └─ Project
            └─ Resource (버킷, 인스턴스 등)

상위 노드에 부여한 allow policy는 하위 노드로 상속됩니다. 어떤 리소스의 유효 권한(effective policy) 은 그 리소스에 직접 설정된 policy와 상위에서 상속된 policy의 합집합(union) 입니다.

6.1 상속이 만드는 실무 함정

조직 수준에서 누군가에게 Editor를 부여했다면, 그 아래 모든 폴더·프로젝트·리소스에 Editor가 적용됩니다. 프로젝트 단위에서 권한을 좁게 설정했다고 안심해도, 상위에서 내려온 권한 때문에 실제로는 넓은 접근이 가능할 수 있습니다.

주의
IAM에서 어떤 Principal의 실제 권한을 판단할 때는 해당 리소스의 policy만 보면 안 됩니다. 상위 계층에서 상속된 권한까지 함께 확인해야 합니다. "이 프로젝트에는 권한을 안 줬는데 왜 접근되지?"의 원인은 대부분 상위 계층 상속입니다.

권한을 부여할 위치를 정할 때는 "이 권한이 하위 전체에 퍼져도 괜찮은가"를 기준으로 판단합니다. 넓게 적용해도 되는 권한은 상위에, 특정 리소스에만 필요한 권한은 가장 낮은 계층에 부여하는 것이 최소 권한 원칙에 맞습니다.

7. AWS IAM과 비교하면

AWS에 익숙하다면 용어 매핑으로 빠르게 이해할 수 있습니다. 다만 1:1로 똑같지는 않습니다.

관점	AWS IAM	GCP IAM
권한을 받는 주체	User, Role, Group	Principal (사용자, 서비스 계정, 그룹, 도메인)
권한 묶음	Policy (JSON 문서)	Role (permission collection)
권한 부여 방식	Principal/Role에 Policy attach	Resource에 allow policy로 Role binding
정책이 붙는 위치	주로 Identity(또는 리소스)	주로 Resource(계층 노드 포함)
권한 상속	명시적 (계정 단위, 상속 개념 약함)	계층 구조 기반 상속이 기본

가장 큰 사고방식 차이는 policy가 붙는 위치입니다. AWS는 보통 "신원(Identity)에 정책을 붙인다"는 관점이 강하고, GCP는 "리소스에 정책을 붙이고, 그 리소스 계층을 따라 상속된다"는 관점이 기본입니다.

또 하나, AWS의 IAM Role은 "임시로 맡는(assume) 자격 증명"이라는 의미가 강하지만, GCP의 Role은 단순히 "Permission 묶음"입니다. GCP에서 AWS의 assume role에 가까운 개념은 서비스 계정 및 그 사용 권한(impersonation) 쪽에 해당합니다.

8. 실무 사용 사례

사례 1: 개발자에게 특정 버킷 읽기 권한만 주기

도입부의 문제 상황을 올바르게 해결해봅니다. 개발자가 로그 버킷의 객체만 조회하면 되는 경우입니다.

gcloud storage buckets add-iam-policy-binding gs://my-log-bucket \
  --member="user:alice@example.com" \
  --role="roles/storage.objectViewer"

이 명령은 my-log-bucket이라는 Resource에만 allow policy binding을 추가합니다. Principal은 alice, Role은 roles/storage.objectViewer입니다. 프로젝트 전체가 아니라 버킷 하나로 범위가 한정됩니다.

Editor를 프로젝트에 부여하는 방식과 비교하면, 사고 발생 시 피해 범위가 버킷 하나로 줄어듭니다. 이것이 "어디에(Resource)"를 좁히는 설계의 효과입니다.

사례 2: 애플리케이션에 서비스 계정으로 권한 부여

Compute Engine에서 동작하는 애플리케이션이 Cloud Storage에 파일을 써야 하는 상황입니다.

잘못된 방법: 서비스 계정 키 파일(JSON)을 발급받아 인스턴스에 넣고 코드에서 읽습니다. 키가 유출되면 장기간 악용될 수 있습니다.

권장 방법: 인스턴스에 서비스 계정을 연결(attach)하고, 그 서비스 계정에 필요한 Role만 부여합니다.

# 서비스 계정에 객체 생성 권한 부여 (특정 버킷에만)
gcloud storage buckets add-iam-policy-binding gs://app-upload-bucket \
  --member="serviceAccount:app@my-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectCreator"

인스턴스에 연결된 서비스 계정은 메타데이터 서버를 통해 단기 토큰을 자동으로 발급받습니다. 키 파일을 직접 다루지 않으므로 유출 위험이 줄어듭니다.

사례 3: 팀 단위 권한 관리

개발자 10명에게 같은 권한을 줘야 한다면, 10명을 각각 binding에 추가하는 대신 Google 그룹을 Principal로 사용합니다.

gcloud projects add-iam-policy-binding my-project \
  --member="group:dev-team@example.com" \
  --role="roles/viewer"

이후 인원이 바뀌면 그룹 멤버십만 수정하면 됩니다. IAM policy 자체는 건드릴 필요가 없습니다. 권한 관리와 인원 관리를 분리하는 패턴입니다.

9. 보안 고려사항

Security Note
GCP IAM에서 가장 흔한 보안 문제는 과도한 Role 부여, 상위 계층 권한 상속의 간과, 서비스 계정 키의 장기 노출입니다. 아래 기준을 기본으로 적용하는 것이 좋습니다.

• Basic Role 지양: Owner/Editor/Viewer는 범위가 너무 넓습니다. predefined role 또는 custom role로 최소 권한을 부여합니다.
• 권한 부여 위치 신중히 선택: 조직/폴더 수준 부여는 하위 전체에 상속됩니다. 넓게 적용돼도 되는 권한만 상위에 둡니다.
• 서비스 계정 키 최소화: 가능하면 키 파일 대신 인스턴스 연결 서비스 계정이나 Workload Identity를 사용합니다. 키 발급이 불가피하면 주기적으로 교체합니다.
• IAM Condition 활용: 시간, 리소스 이름 등 조건으로 권한 적용 범위를 추가로 제한합니다.
• 감사 로그 확인: Cloud Audit Logs로 누가 어떤 권한으로 무엇을 했는지 기록하고 점검합니다.
• Recommender로 권한 점검: IAM Recommender는 실제 사용되지 않는 권한을 식별해 최소 권한 적용을 돕습니다.

10. 비용/운영 고려사항

주의
IAM 자체는 무료지만, 잘못된 권한 설계는 의도치 않은 리소스 생성/삭제로 간접적인 비용 사고를 유발할 수 있습니다.

항목	설명
IAM 서비스 비용	무료 (Principal, Role, policy 설정에 비용 없음)
간접 비용 위험	과도한 권한으로 인한 리소스 오남용 가능성
감사 로그 비용	Cloud Audit Logs 중 Data Access 로그는 별도 저장 비용 발생 가능
운영 부담	custom role이 많아지면 유지보수 복잡도 증가

운영 관점:

• custom role은 새 API/Permission이 추가돼도 자동 갱신되지 않으므로 주기적으로 검토해야 합니다.
• Role과 그룹에 일관된 명명 규칙을 적용하면 권한 추적이 쉬워집니다.
• 권한 변경 전에는 상위 계층 상속까지 포함한 유효 권한을 확인합니다.

11. 자주 하는 실수

1. 버킷 하나 권한을 주려다 프로젝트에 Editor 부여: "어디에(Resource)"를 좁히지 않은 경우입니다. 가능한 가장 낮은 계층에 가장 제한적인 role을 부여합니다.
2. 상위 계층 상속을 잊는 것: 프로젝트 policy만 보고 권한을 판단하면 조직/폴더에서 내려온 권한을 놓칩니다. 유효 권한은 상속을 합산해 확인합니다.
3. Permission을 Principal에 직접 주려는 시도: GCP에서 Permission은 항상 Role을 통해서만 부여됩니다. 필요한 Permission을 담은 predefined/custom role을 찾거나 만듭니다.
4. 서비스 계정 키 남발: 키 파일은 장기 자격 증명입니다. Git에 커밋되거나 로그에 남으면 유출됩니다. 인스턴스 연결 서비스 계정이나 Workload Identity를 우선 검토합니다.
5. 사람마다 개별 binding 추가: 인원 변동 시 관리가 어려워집니다. 그룹을 Principal로 사용해 권한과 인원 관리를 분리합니다.

12. 정리

• GCP IAM은 "Principal에게 Resource에 대한 Role을 grant한다"는 한 문장으로 요약됩니다.
• Permission은 service.resource.verb 형식이며, Principal에게 직접 줄 수 없고 Role을 통해서만 부여됩니다.
• Allow policy는 role binding(Principal + Role + Condition)의 모음이며 Resource에 붙습니다.
• 상위 계층 권한은 하위로 상속되므로, 유효 권한은 상속을 포함해 판단해야 합니다.
• 운영 환경에서는 basic role을 피하고, predefined role을 우선 사용하며, 가장 낮은 계층에 최소 권한을 부여하는 것이 안전합니다.

참고 문서

• Google Cloud 공식 문서: IAM overview
• Google Cloud 공식 문서: Roles overview
• Google Cloud 공식 문서: Allow policies
• Google Cloud 공식 문서: Using resource hierarchy for access control
• Google Cloud 공식 문서: Using IAM securely