您可以透過允許政策授予 Google Cloud 資源的存取權，這類政策會附加於資源。每項資源只能附加一項允許政策。 允許政策可控管資源本身的存取權，以及沿用允許政策的資源後代。
這個頁面會以 JSON 格式顯示允許政策。您也可以使用 Google Cloud CLI，以 YAML 格式擷取允許政策。
政策結構
允許政策是一組角色繫結和中繼資料。角色繫結會指定應授予資源的存取權。這項繫結會將一或多個主體與單一 IAM 角色建立關聯，並指定任何與環境相關的條件，藉此變更角色的授予方式和時間。中繼資料包含允許政策的其他資訊，例如 etag 和版本，方便管理政策。
每個角色繫結可包含下列欄位：
- 一或多個主體，又稱為成員或身分。主體類型有很多種，包括單一使用者、使用者群組和服務帳戶。如需支援的主體類型完整清單，請參閱「主體類型」。
- 「角色」是一組已命名的權限，可讓您對 Google Cloud資源執行動作。
條件：選用的邏輯運算式，可根據要求屬性 (例如來源或目標資源) 進一步限制角色繫結。條件通常用於根據要求的內容，控管是否授予存取權。
如果角色繫結包含條件，則稱為條件式角色繫結。
部分 Google Cloud 服務不接受允許政策中的條件。 如要查看可接受條件的服務和資源類型清單，請參閱「可接受條件式角色綁定的資源類型」。
主體存取權的變更具有最終一致性。因此存取權變更需要一段時間才會全面套用到系統。如要瞭解存取權變更平均需要多久才會生效，請參閱「存取權變更生效」一文。
所有主體的限制
每項允許政策最多可包含 1,500 個主體。
為計算這項限制，身分與存取權管理會計算允許政策角色繫結中，每位主體的「所有」出現次數，以及允許政策「免除資料存取稽核記錄」的主體。而「不會」捨棄相同主體在不同角色繫結中重複出現的次數。舉例來說，假設允許政策只包含主體 user:my-user@example.com 的角色繫結，且這個主體出現在 50 個角色繫結中，那麼您可以在允許政策的角色繫結中再新增 1,450 個主體。
此外，就這項限制而言，無論網域或 Google 群組中有多少個別成員，每個網域或群組都會計為一個主體。
如果您使用 IAM 條件，或是授予許多主體角色，且這些主體的 ID 異常長，則 IAM 可能會在允許政策中允許較少主體。
群組和網域的限制
在允許政策中，最多可有 250 個主體是 Google 群組、Cloud Identity 網域或 Google Workspace 帳戶。
為計算這項限制，Cloud Identity 網域、Google Workspace 帳戶和 Google 群組的計數方式如下：
- 如果是 Google 群組，無論群組在允許政策中出現幾次，每個不重複的群組只會計入一次。這與允許政策中主體總數的限制不同，後者會將群組的每次出現計入限制。
- 如果是 Cloud Identity 網域或 Google Workspace 帳戶，IAM 會計算允許政策角色繫結中每個網域或帳戶出現的「所有」次數。但「不會」捨棄相同網域或帳戶在不同角色繫結中重複出現的次數。
舉例來說，如果允許政策只包含一個群組 (group:my-group@example.com)，且該群組在允許政策中出現 10 次，您最多可以再新增 249 個 Cloud Identity 網域、Google Workspace 帳戶或不重複群組，才會達到上限。
或者，如果允許政策只包含一個網域 (domain:example.com)，且該網域在允許政策中出現 10 次，您最多可以再新增 240 個 Cloud Identity 網域、Google Workspace 帳戶或不重複群組，才會達到上限。
政策中繼資料
允許政策的中繼資料包含下列欄位：
etag欄位，用於並行控制，確保允許政策一致更新。詳情請參閱本頁面的「在政策中使用 etag」。version欄位，指定特定允許政策的結構定義版本。詳情請參閱本頁的「政策版本」。
對於機構、資料夾、專案和帳單帳戶，允許政策也可以包含 auditConfig 欄位，指定會為各項服務產生稽核記錄的活動類型。如要瞭解如何設定允許政策的這部分，請參閱設定資料存取稽核記錄。
在政策中使用 etag
如果多個系統嘗試同時寫入相同的允許政策，這些系統可能會覆寫彼此的變更。這是因為允許政策是使用讀取 - 修改 - 寫入模式更新，其中涉及多項作業：
- 讀取現有的允許政策
- 修改允許政策
- 編寫完整的允許政策
如果系統 A 讀取允許政策，而系統 B 立即寫入該允許政策的更新版本，則系統 A 不會知道系統 B 的變更。如果系統 A 將自己的變更寫入允許政策，系統 B 的變更可能會遺失。
為避免發生這個問題，Identity and Access Management (IAM) 支援並行控制，方法是在允許政策中使用 etag 欄位。每個允許政策都包含 etag 欄位，且每次更新允許政策時，這個欄位的值都會變更。如果允許政策包含 etag 欄位，但沒有任何角色繫結，則允許政策不會授予任何 IAM 角色。
etag 欄位包含 BwUjMhCsNvY= 等值。更新允許政策時，請務必在更新後的允許政策中加入 etag 欄位。如果擷取允許政策後，政策經過修改，etag 值就不會相符，更新也會失敗。如果是 REST API，您會收到 HTTP 狀態碼 409 Conflict，且回應主體類似於下列內容：
{
"error": {
"code": 409,
"message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
"status": "ABORTED"
}
}
如果收到這項錯誤，請重試整套作業：再次讀取允許政策、視需要修改，然後寫入更新後的允許政策。您應在用於管理允許政策的任何工具中，自動執行重試作業，並採用指數輪詢策略。
範例：簡單政策
請參考下列允許政策，將主體繫結至角色：
{
"bindings": [
{
"members": [
"user:jie@example.com"
],
"role": "roles/owner"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
在上例中，系統會無條件授予 Jie Owner 基本角色。這個角色幾乎授予 Jie 無限制的存取權。
範例：具有多個角色繫結的政策
請參考下列允許政策，其中包含多個角色繫結。 每個角色繫結都會授予不同的角色：
{
"bindings": [
{
"members": [
"user:jie@example.com"
],
"role": "roles/resourcemanager.organizationAdmin"
},
{
"members": [
"user:raha@example.com",
"user:jie@example.com"
],
"role": "roles/resourcemanager.projectCreator"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
在上述範例中，第一個角色繫結會將預先定義的機構管理員角色 (roles/resourcemanager.organizationAdmin) 授予 Jie。這個角色包含組織、資料夾和有限專案作業的權限。在第二個角色繫結中，Jie 和 Raha 都透過專案建立者角色 (roles/resourcemanager.projectCreator) 獲得專案建立權。這些角色繫結共同授予 Jie 和 Raha 細微的存取權，且 Jie 獲得的存取權比 Raha 多。
範例：含有條件式角色繫結的政策
請參考下列允許政策，這項政策會將主體繫結至預先定義的角色，並使用條件運算式限制角色繫結：
{
"bindings": [
{
"members": [
"group:prod-dev@example.com",
"serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
],
"role": "roles/appengine.deployer",
"condition": {
"title": "Expires_July_1_2022",
"description": "Expires on July 1, 2022",
"expression":
"request.time < timestamp('2022-07-01T00:00:00.000Z')"
}
}
],
"etag": "BwWKmjvelug=",
"version": 3
}在本例中，version 欄位設為 3，因為允許政策包含條件運算式。允許政策中的角色繫結是有條件的，會將角色授予 prod-dev 群組和服務帳戶 prod-dev-example@appspot.gserviceaccount.com，但只到 2022 年 7 月 1 日為止。
如要進一步瞭解各個允許政策版本支援的功能，請參閱這個頁面的「政策版本」一節。
範例：包含條件式和無條件角色繫結的政策
請參考下列允許政策，其中包含相同角色的條件式和無條件角色繫結：
{
"bindings": [
{
"members": [
"serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
],
"role": "roles/appengine.deployer"
},
{
"members": [
"group:prod-dev@example.com",
"serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
],
"role": "roles/appengine.deployer",
"condition": {
"title": "Expires_July_1_2022",
"description": "Expires on July 1, 2022",
"expression":
"request.time < timestamp('2022-07-01T00:00:00.000Z')"
}
}
],
"etag": "BwWKmjvelug=",
"version": 3
}在本範例中，服務帳戶 serviceAccount:prod-dev-example@appspot.gserviceaccount.com 包含在相同角色的兩個角色繫結中。第一個角色繫結沒有條件。第二個角色繫結設有條件，只授予角色到 2022 年 7 月 1 日。
實際上，這項允許政策一律會將角色授予服務帳戶。在 IAM 中，條件式角色繫結不會覆寫沒有條件的角色繫結。如果主體繫結至角色，且角色繫結沒有條件，則主體一律會擁有該角色。為相同角色新增主體至條件式角色繫結，不會有任何效果。
相較之下，prod-dev 群組只會納入條件式角色繫結。因此，該使用者只會在 2022 年 7 月 1 日前擁有該角色。
範例：將角色繫結至已刪除主體的政策
請參考下列允許政策。這項允許政策會將角色繫結至已刪除的服務帳戶 serviceAccount:my-service-account@my-project.iam.gserviceaccount.com。因此，服務帳戶的 ID 現在會加上 deleted: 前置字串：
{
"bindings": [
{
"members": [
"deleted:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com?uid=123456789012345678901"
],
"role": "roles/owner"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
如果您建立同名的新服務帳戶，允許政策中已刪除服務帳戶的角色繫結，就不會套用至新服務帳戶。這項行為適用於所有類型的已刪除主體。
這樣一來，新主體就不會繼承授予已刪除主體的角色。如要將角色授予新主體，請將新主體新增至允許政策的角色繫結，如本頁的「已刪除主體的政策」所示。
所有已刪除的主體都會加上 deleted: 前置字元。部分已刪除主體類型 (例如服務帳戶) 也會加上 ?uid=numeric-id 後置字串，其中 numeric-id 是已刪除主體的唯一數字 ID。在本例中，允許政策會顯示 deleted:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com?uid=123456789012345678901 識別碼，而非 serviceAccount:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com。
預設政策
所有接受允許政策的資源都會使用預設允許政策建立。大多數資源的預設允許政策都是空白。
不過，部分資源的預設允許政策會自動包含特定角色繫結。舉例來說，當您建立新專案時，專案的允許政策會自動建立角色繫結，將專案的擁有者角色 (roles/owner) 授予您。
這些角色繫結是由系統建立，因此使用者不需要資源的 getIamPolicy 或 setIamPolicy 權限，即可建立角色繫結。
如要瞭解資源是否是透過允許政策建立，請參閱資源的說明文件。
政策沿用和資源階層
Google Cloud 資源有階層分明的組織架構，以機構節點做為階層的根節點，然後是選用的資料夾，最後是專案。其他大部分資源都是在專案底下建立及管理。除了機構之外，每項資源都只有一個父項。機構是階層結構中的根節點，因此沒有父項。詳情請參閱「資源階層」主題。
設定允許政策時，請務必考量資源階層。在階層中較高的層級 (例如機構、資料夾或專案層級) 設定允許政策時，授予的存取權範圍會包括附加這項允許政策的資源層級，以及該層級下的所有資源。舉例來說，在機構層級設定的允許政策會套用至該機構和機構下的所有資源。同樣地，在專案層級設定的允許政策會套用至專案和專案中的所有資源。
政策繼承是指允許政策如何套用至資源階層中該層級以下的資源。「有效政策」是指資源在資源階層中，如何沿用所有父項允許政策。這是下列項目的聯集：
- 資源上設定的允許政策
- 在階層中，針對資源的所有祖先資源層級設定的允許政策
系統會分別評估每個影響資源有效允許政策的新角色繫結 (從父項資源繼承)。如果任何較高層級的角色繫結授予要求存取權，系統就會授予資源的特定存取要求。
如果資源的任何層級導入新的角色繫結，資源的繼承許可政策就會擴大存取權授予範圍。
範例：政策繼承
如要瞭解允許政策的繼承行為，請考量以下情境：您在資源階層的兩個不同層級，將兩個不同的 IAM 角色授予使用者 Raha。
如要授予 Raha 機構層級角色，請在機構中設定下列允許政策：
{
"bindings": [
{
"members": [
"user:raha@example.com"
],
"role": "roles/storage.objectViewer"
}
],
"etag": "BwUjMhCsNvY=",