IAM 決定資源的存取權限,
Role是權限的集合,
Policy是把role指派給成員的規則

IAM = Identity and Access Management 決定誰能在什麼資源做什麼

參考文件 doc

權限的理解可以從 permission, role, policy三層結構

permission是最小單位 像是 compute.instance.create(建立虛擬機), 是google預設好的一種權限, 不需要人手動定義這個規則

role代表角色, 在POC階段可以採用basic role像是 owner, editor, viewer, 故名思義就是擁有者(全部權限), 可以編輯資源者, 只能查看的人, 不過在上線環境一定會有更細緻的權責區分, 所以會採用custom roles, 我們不能直接把權限指派給人, 而是把多個權限包進一個角色, 像是SRE這個角色可以新增刪除機器, 也可以查看log

三種role層級

basic role - gcp預設配置的role, who can do what on ‘all resources’

predefined role - who can do what on ‘which resource’ (像是compute engine user, cloud sql user)由google是先定義好的role

custom role - 自行建立

policy則是一張綁定清單, 設定誰綁定了什麼角色

在文件中有說明, 所謂的主體(principle), 也就是誰, 在系統上可以是一個人, 也可以是workload, 可以理解是程式, 腳本, 機器, 想像機器在執行任務時會產生log, 可能也要動態的啟動關閉機器, 他也需要特定的permission, 也常會稱之為service account

實作驗證

進入gcp console, 點擊IAM > IAM

這時候可以看到自己是owner, 接著點選grant access來邀請人

我邀請我自己另一個帳號(以前想學aws(誤)創的帳號)

給予他 cloud run viewer, dialogflow api reader的role

就可以看到這個專案現在有兩個主體了

我開無痕視窗 用另一個帳號(jojo.aws.develop@gamil)登入 也去到gcp console,

選擇剛才的專案 2026-chat-bot

打開cloud run管理畫面

因為在這專案中, 這個身份只有cloud run viewer身份, 所以一切操作都是disabled

對比owner帳號, 服務都還沒啟動, 不過是可以操作的

owner 從IAM可以看到專案中有哪些帳號 (看到帳號列表也是一個權限)

當我們有建立role和principle的關係 google就會產生policy 也就是表色和本體的綁定

可以透過console來查詢

進入console 輸入 gcloud projects get-iam-policy <project-id>

就能查到當下的binding:

建立Service account

IAM > service accounts

這個sa可以想像是一個憑證, 當我們之後要和dialogflow 溝通時 需要有這個憑證才能使用這個服務

建立如下 命名, 敘述; id則是會自動產生

賦予以下三個role (來自gemini的協助)

然後就可以建立sa了

現在在IAM就可以看到sa以及兩個user了

到此的進度

1. viewer和owner兩個用戶可以進來gcp管理專案
2. service account管理權限, 日後用戶向bff詢問時, bff就要帶上sa的憑證向dialogflow查詢

回頭來看IAM的預設角色 basic role - viewer, editor, owner
其實權限真的很大, 就算是viewer, 也可以看到所有的資源狀態, 這在實務上不大可能的
因為這樣就看光專案上所有的設定, 可能只會存在POC這種只求驗證的情境