Role Types trong GCP IAM — Basic, Predefined, Custom

Tại sao role design quan trọng

Role là đơn vị cấp phát quyền trong IAM. Một role không phải là "một quyền" mà là một tập hợp permissions — và sự khác biệt này quan trọng hơn nhiều người nghĩ. Chọn sai role type trong production có thể dẫn đến: blast radius quá rộng khi compromise một service account, vi phạm audit compliance requirements, hoặc không tuân thủ được least-privilege mandate.

Hệ thống role trong GCP được thiết kế theo triết lý: coarse-grained access cho đơn giản, fine-grained access khi cần kiểm soát chặt. Việc hiểu cấu trúc bên trong của từng role type giúp engineer đưa ra quyết định đúng thay vì mặc định chọn role rộng nhất cho tiện.

Permission naming model

Trước khi đi vào role types, cần hiểu cấu trúc của permissions trong GCP.

Mỗi permission có format:

SERVICE.RESOURCE_TYPE.ACTION

Ví dụ:

storage.objects.get — Cloud Storage service, đối tượng object, hành động đọc
compute.instances.create — Compute Engine, instance resource, tạo mới
iam.serviceAccounts.actAs — IAM service, service account, thực thi as

Service là phần định danh GCP service (storage, compute, iam, bigquery...). Resource type là loại resource trong service đó. Action là verb (get, create, update, delete, list, use, actAs...).

Một số permissions đặc biệt không theo pattern này:

resourcemanager.projects.getIamPolicy — lấy IAM policy của project
iam.roles.create — tạo custom role

Permission granularity

Cùng một resource type, GCP cung cấp permissions ở nhiều mức granularity:

storage.objects.get        ← đọc một object
storage.objects.list       ← liệt kê objects trong bucket
storage.objects.create     ← tạo object mới
storage.objects.update     ← cập nhật metadata object
storage.objects.delete     ← xóa object
storage.objects.*          ← wildcard (chỉ dùng trong Deny Policy, không phải Allow)

Điều này cho phép thiết kế quyền rất chi tiết — nhưng quản lý hàng trăm individual permissions không thực tế, đó là lý do roles tồn tại.

Basic Roles: Legacy và Nguy hiểm trong Production

Basic roles (còn gọi là primitive roles) là ba role được tạo ra từ thời GCP mới ra đời, trước khi GCP có hệ thống IAM granular. Chúng là:

Role	Identifier	Phạm vi quyền
Owner	`roles/owner`	Full access toàn bộ service, bao gồm quản lý IAM
Editor	`roles/editor`	Read/write access hầu hết service, không manage IAM
Viewer	`roles/viewer`	Read-only access hầu hết service

Tại sao basic roles nguy hiểm

1. Quá rộng về scope:

roles/editor trong một project bao gồm hàng nghìn permissions trên hàng chục GCP services. Khi grant Editor cho một service account chỉ cần đọc Cloud Storage, bạn vô tình cũng grant:

Quyền đọc/ghi tất cả GCS buckets trong project
Quyền tạo/dừng Compute Engine instances
Quyền đọc BigQuery datasets
Quyền push metrics và traces
Quyền tạo Cloud Functions
...và hàng trăm quyền khác

Nếu service account bị compromise, blast radius là toàn bộ project.

2. Quyền IAM management:

roles/owner bao gồm permission resourcemanager.projects.setIamPolicy — tức là owner có thể tự grant cho mình bất kỳ role nào khác, hoặc grant cho attacker. Đây là nguồn gốc của nhiều privilege escalation incidents.

3. Không audit được:

Vì basic roles bao gồm quá nhiều permissions, khi audit "tại sao entity này có quyền X", câu trả lời thường là "vì có roles/editor" — không tracking được ai grant, tại sao, và không có granularity để revoke chỉ quyền X mà giữ các quyền khác.

4. Không thể dùng với Conditions:

Basic roles không hỗ trợ IAM Conditions. Không thể giới hạn Editor role "chỉ trong giờ hành chính" hay "chỉ với resource trong environment prod".

Production rule: Không bao giờ grant basic roles (Owner/Editor/Viewer) cho service accounts hoặc trong production environments. Chỉ chấp nhận Viewer role trong một số trường hợp monitoring/observability có justification rõ ràng.

Predefined Roles: Chuẩn của Google

Predefined roles là tập roles được Google tạo và quản lý cho từng GCP service. Đây là loại role nên dùng trong phần lớn trường hợp production.

Cách Google thiết kế predefined roles

Mỗi GCP service thường có một bộ predefined roles theo pattern:

roles/SERVICE.admin        ← Full access service đó
roles/SERVICE.editor       ← Read/write nhưng không quản lý IAM
roles/SERVICE.viewer       ← Read-only
roles/SERVICE.SPECIFIC_*   ← Role cho use case cụ thể

Ví dụ cho Cloud Storage:

roles/storage.admin — Full control buckets và objects
roles/storage.objectAdmin — Full control chỉ objects (không control bucket)
roles/storage.objectCreator — Chỉ tạo objects, không đọc
roles/storage.objectViewer — Chỉ đọc objects
roles/storage.legacyBucketOwner — Legacy role, không dùng production

Predefined roles được quản lý thế nào

Google có quyền thêm permissions vào predefined roles khi ra mắt tính năng mới, nhưng không remove permissions đã có (để tránh break existing workflows). Điều này có hai implications:

Predefined roles có thể tự "mở rộng" theo thời gian: Một service account với roles/compute.instanceAdmin hôm nay có thể tự động có thêm quyền mới khi Google release Compute Engine feature mới. Đây là điều cần cân nhắc trong strict compliance environments.
Tracking permission changes: Google publish changelog cho predefined role updates tại https://cloud.google.com/iam/docs/permissions-change-log. Các security teams nên subscribe để biết khi có role expansion.

Tìm predefined role phù hợp

Nguyên tắc: chọn role hẹp nhất đáp ứng đủ use case, không chọn role rộng hơn cần thiết.

Workflow thực tế:

Xác định permissions cụ thể cần thiết (bằng cách test hoặc đọc docs của service)
Tìm predefined role bao gồm đủ permissions đó bằng gcloud iam roles describe ROLE_NAME
Nếu có predefined role khớp gần đúng với ≤ 20% permissions thừa → chấp nhận
Nếu predefined role nhỏ nhất vẫn quá rộng → cân nhắc custom role

bash

# Xem tất cả permissions trong một predefined role
gcloud iam roles describe roles/storage.objectViewer

# Tìm predefined roles liên quan đến một service
gcloud iam roles list --filter="name:roles/storage.*" \
  --format="table(name, title)"

# Xem permissions của một role ở project/org level
gcloud iam roles describe ROLE_NAME \
  --project=PROJECT_ID

Custom Roles: Kiểm soát tối đa, chi phí vận hành cao

Custom roles là roles do người dùng tạo với bộ permissions tùy chỉnh. Chúng cần thiết khi không có predefined role nào phù hợp với yêu cầu least-privilege.

Phạm vi của custom roles

Custom roles có thể tạo ở hai cấp:

Project-level: Chỉ có thể gán trong project đó
Organization-level: Có thể gán trên mọi resource trong organization

Giới hạn quan trọng:

Tối đa 300 custom roles per project
Tối đa 100 custom roles per organization
Một custom role có thể có tối đa 3000 permissions

Permissions nào có thể thêm vào custom role

Không phải tất cả permissions đều có thể thêm vào custom roles. GCP chia permissions thành các support levels:

Level	Ý nghĩa
`SUPPORTED`	Có thể thêm vào custom role, hoạt động như expected
`TESTING`	Đang trong testing phase, behavior có thể thay đổi
`NOT_SUPPORTED`	Không thể thêm vào custom role

Permissions NOT_SUPPORTED thường là những permissions đặc biệt (admin bootstrapping, internal GCP operations). Khi tạo custom role với permission không hợp lệ, API trả về error.

bash

# Kiểm tra support level của permission
gcloud iam list-testable-permissions \
  //cloudresourcemanager.googleapis.com/projects/PROJECT_ID \
  --filter="customRolesSupportLevel=SUPPORTED"

Custom role lifecycle

Custom roles có stage để track maturity:

ALPHA → BETA → GA → DEPRECATED → DISABLED → DELETED

DISABLED: Role vẫn tồn tại nhưng không thể gán, các bindings hiện tại bị revoke
DELETED: Soft-deleted, có thể undelete trong 7 ngày

Vấn đề vận hành của custom roles

Custom roles tạo ra operational overhead đáng kể:

Permission drift: Khi GCP service release features mới, predefined roles tự động cập nhật nhưng custom roles thì không. Team phải manually review và update custom roles định kỳ.
Version tracking: Mỗi lần update custom role tạo ra một version mới. Cần quy trình review/approval rõ ràng.
Không scale với số lượng lớn: Với 300 custom roles/project limit, organizations lớn với nhiều services và teams cần cân nhắc carefully.
Testing complexity: Validate rằng custom role có đúng permissions cần thiết (không thiếu, không thừa) yêu cầu test riêng.

Khi nào nên dùng custom roles:

Predefined role gần nhất có permissions nhạy cảm không cần thiết (ví dụ: storage.buckets.delete)
Compliance requirements bắt buộc document và justify từng permission
Workloads có threat model yêu cầu cực kỳ strict least-privilege

Khi nào không nên dùng custom roles:

Team nhỏ không có bandwidth maintain custom roles
Predefined roles đã đủ good với ≤ 20% permissions thừa và không có quyền sensitive
Rapid prototyping / non-production environments

IAM Recommender và Role Design

Một công cụ quan trọng khi thiết kế roles là IAM Recommender — phân tích 90 ngày lịch sử access để đề xuất roles phù hợp hơn. Khi đang dùng broad roles (Editor, Admin), Recommender thường đề xuất REPLACE_ROLE_CUSTOMIZABLE — tạo custom role với chính xác những permissions đã được dùng.

Cơ chế chi tiết của Recommender được phân tích ở Chapter 31 - File 10.

Role Binding Best Practices ở Production Scale

Group-based bindings thay vì individual bindings

Thay vì grant role cho từng user individual, dùng Google Groups:

Không nên:
  alice@example.com → roles/storage.objectViewer
  bob@example.com   → roles/storage.objectViewer
  carol@example.com → roles/storage.objectViewer

Nên:
  data-team@example.com → roles/storage.objectViewer
  (alice, bob, carol là members của group)

Lý do: Group membership quản lý dễ hơn, reduce policy size, không cần update IAM policy khi onboard/offboard user.

Service Account per Workload

Mỗi workload (mỗi microservice, mỗi Cloud Function, mỗi GKE deployment) nên có service account riêng với chính xác những roles cần thiết. Đừng dùng chung service account vì tiện lợi — khi một workload bị compromise, attacker chỉ có quyền của workload đó, không phải của toàn bộ platform.

Org-level vs Project-level binding

Nguyên tắc: bind ở mức thấp nhất có thể. Nếu một team chỉ cần access một project, grant role ở project level, không phải org level. Inheritance chỉ nên được dùng có chủ đích (ví dụ: team security cần viewer access trên toàn org để audit).

Role Types trong GCP IAM — Basic, Predefined, Custom ​

Tại sao role design quan trọng ​

Permission naming model ​

Permission granularity ​

Basic Roles: Legacy và Nguy hiểm trong Production ​

Tại sao basic roles nguy hiểm ​

Predefined Roles: Chuẩn của Google ​

Cách Google thiết kế predefined roles ​

Predefined roles được quản lý thế nào ​

Tìm predefined role phù hợp ​

Custom Roles: Kiểm soát tối đa, chi phí vận hành cao ​

Phạm vi của custom roles ​

Permissions nào có thể thêm vào custom role ​

Custom role lifecycle ​

Vấn đề vận hành của custom roles ​

IAM Recommender và Role Design ​

Role Binding Best Practices ở Production Scale ​

Group-based bindings thay vì individual bindings ​

Service Account per Workload ​

Org-level vs Project-level binding ​

References ​