Google Distributed Cloud (GDC) 實體隔離方案中的 Identity and Access Management (IAM) 可讓您控管哪些使用者能存取哪些資源，以及他們可以對這些資源執行哪些操作。
瞭解 IAM 在 GDC 中的運作方式，有助於有效管理存取權，確保成員具備執行角色所需的權限，同時維護實體隔離環境的安全。
本文適用於平台管理員和應用程式操作員群組 (例如 IT 管理員、資安工程師或應用程式開發人員)，協助他們瞭解 GDC 實體隔離方案的授權和存取控管機制。此外，本文也有助於基礎架構操作人員建立存取控管概念的基本知識。詳情請參閱 GDC 實體隔離方案說明文件的目標對象。
存取控管模型
GDC 存取權架構包含三個核心元件：成員 (誰)、角色 (什麼) 和資源範圍 (哪裡)。
存取控管分為兩個階段：證明身分 (驗證) 和決定可執行的操作 (授權)：
- 驗證：GDC 不會儲存使用者帳戶或密碼。GDC 會連線至貴組織的識別資訊提供者 (IdP)，方便您使用公司憑證登入。
- 授權：驗證後，GDC IAM 會檢查指派給您的角色，判斷您可以存取哪些資源，以及執行哪些動作。
成員
成員是可授予資源存取權的身分。GDC 會根據管理位置，將成員分為兩大類：人類身分和非人類身分。
真人身分
人類身分是指登入 GDC 的使用者和群組。GDC 不會儲存使用者帳戶或密碼，而是使用 OpenID Connect (OIDC) 或 SAML 2.0 等標準身分聯合通訊協定，連結至貴組織現有的登入系統或 IdP (例如 Active Directory、LDAP 或 Okta)。
人類身分分為兩種類型：
- 使用者：使用公司憑證登入系統的個別使用者。
- 群組：在組織 IdP 中管理的人類使用者集合。將角色授予群組後，該群組的所有成員都會自動獲得該角色。
GDC 會使用 IdP 識別人類身分。由於環境可以連結至多個 IdP (例如不同部門使用不同的登入系統)，GDC 會區分 IdP，確保您將存取權授予正確的使用者。
管理存取權時，GDC 會自動在所有外部使用者名稱和群組前面加上專屬 IdP 前置字元：
- 格式：
idpprefix-username@domain.com(如果是群組，則為idpprefix-group-name)。 - 範例：如果貴組織的 IdP 設定前置字串為
agency-a，而您以alice@example.com登入，GDC IAM 會將您視為agency-a-alice@example.com。
非真人身分
非人類身分稱為服務身分 (或服務帳戶)。您可以直接在 GDC 中建立及管理服務帳戶 (做為 ProjectServiceAccount 資源)，讓應用程式、指令碼或自動化工作負載安全地與 API 互動。
服務帳戶由 GDC 內部管理，因此不使用 IdP 前置字元。而是透過專案和名稱來識別 (例如使用 gdcloud CLI 時，為 serviceAccount:projectName:serviceAccountName)。
詳情請參閱「保護服務帳戶金鑰」。
權限與角色
權限是指對資源執行特定動作的授權 (例如建立 VM 或刪除資料庫)。您不會直接授予權限給成員，而是將權限組合成角色。
GDC 提供兩種角色：
- 預先定義的角色：由 GDC 建立及管理的內建權限組合。GDC 提供完整的預先定義角色程式庫，可依特定工作職能和服務量身打造 (從專案檢視者等廣泛角色，到值區專案管理員或 KMS 檢視者等精細服務角色)。
- 自訂角色：如果現有的預先定義的角色不符合組織需求，您可以自行建立權限組合。
透過 IAM 角色授予的權限純粹是累加性質，只會授予存取權，不含拒絕規則。如果將多個角色授予成員，成員會取得這些角色中所有權限的聯集。如要限制或拒絕整個組織存取特定服務，可以設定組織政策。
資源範圍
您一律在 GDC 資源階層的特定層級授予存取權。範圍會決定成員可以存取哪些資源。在多可用區環境中，根據預設，在任一範圍指派的角色會自動套用至所有可用區。
您可以在下列資源範圍授予角色：
- 組織：環境的頂層容器。在組織層級授予的角色會套用至整個組織，並自動繼承至組織內的所有專案和資源。
- 專案：組織內的容器，用於將特定團隊或應用程式的資源分組。專案是嚴格的安全界線，在專案層級授予的角色，僅適用於該專案及其資源 (例如虛擬機器、資料庫和 Kubernetes 叢集)。
詳情請參閱「資源階層」和「多可用區資料庫的權限控管」。
如何授權存取
GDC 主要使用角色式存取控管 (RBAC) 模型，管理及授權存取權。在 RBAC 模型中，您不會直接將權限指派給個別使用者或工作負載，而是將角色指派給特定資源範圍內的成員，藉此決定存取權。
GDC 使用下列 Kubernetes 自訂資源實作 RBAC：
IAMRole：定義一組特定權限。IAMRoleBinding：在組織或專案範圍內，將成員 (人類使用者、群組或服務帳戶) 連結至IAMRole。
如要授予組織或專案資源的存取權，您可以使用 GDC 控制台、gdcloud CLI 建立 IAMRoleBinding，或使用 kubectl CLI 套用自訂資源資訊清單 (YAML 檔案)。
舉例來說，如要允許團隊成員查看專案中的虛擬機器，您可以在該專案的範圍內建立 IAMRoleBinding，將成員的身分連結至檢視者角色。當成員嘗試查看虛擬機器時，GDC 會檢查其有效的角色繫結，確認指派的角色包含必要權限，並授權要求。
雖然 GDC 控制台和 gdcloud CLI 會自動連線至資源，但使用 kubectl CLI 直接存取 API 時，必須產生 kubeconfig 檔案，向託管該資源的特定 Kubernetes 叢集或 API 伺服器進行驗證。詳情請參閱「登入並產生 kubeconfig 檔案」。
如要進一步瞭解如何管理角色繫結，請參閱「授予及撤銷存取權」。
GDC 實體隔離方案 IAM 與 Google Cloud的差異
如果您有管理 Google Cloud存取權的經驗，GDC 會使用類似的概念，但實作方式不同，以便在實體隔離的 Kubernetes 基礎架構中運作。
下表比較 GDC 和 Google Cloud中的 IAM：
| 功能 | 說明 | GDC 實體隔離方案 | Google Cloud |
|---|---|---|---|
| 使用者身分 (驗證) | 用於驗證人類使用者的身分系統。 |
使用必要的 IdP 前置字元 (例如 idpprefix-user@domain.com)，與外部 IdP 建立聯盟。 |
Google 帳戶 (例如 Gmail) 或透過 Cloud Identity 或 Google Workspace 建立的企業身分。 |
| 授權引擎 | 評估及強制執行權限的基礎系統。 | 主要是 Kubernetes 角色式存取控管 (RBAC)，其中 API 伺服器會在本機根據角色繫結評估存取要求。您可以使用組織政策設定資源限制。 | Google 的全球 Cloud IAM 服務。集中評估 API 要求，並與資源階層中任何層級附加的存取權政策進行比對。 |
| 角色繫結 | 成員如何對應至特定資源的角色。 |
個別 IAMRoleBinding 自訂資源。每個繫結都是將成員連結至一個角色的物件。IAM 角色權限純粹是累加性質 (拒絕規則可透過組織政策另外設定)。 |
附加至各項資源、資料夾或組織的單一 IAM 存取權政策。包含多個繫結，可將成員對應至角色，並支援條件式規則或拒絕規則。 |
| 服務帳戶 | 應用程式和自動化工作負載使用的非真人身分。 |
在特定專案 (ProjectServiceAccount) 中建立的本機服務帳戶。公開金鑰會儲存在叢集中，私密金鑰則由用戶端在本機管理及保護。 |
由 Google 集中管理的全球身分。憑證可由 Google 自動管理，或下載為金鑰檔案，以便從任何位置進行驗證。 |
| 資源階層結構 | 用於整理資源及繼承權限的容器結構。 | 兩層階層結構：機構 > 專案 | 多層階層結構：機構 > 資料夾 > 專案 |
| 多可用區權限範圍 | 系統如何評估權限，並將權限傳播至各個可用區或區域。 | 使用由全域 API 伺服器管理的 Kubernetes RBAC，該伺服器會協調及複製可用區 API 伺服器中的角色繫結，因此預設會將存取權套用至所有可用區。 | 採用全代管的全球 IAM 服務。在任何資源層級指派的權限本質上都是全域性，會自動套用至所有區域和可用區。 |
| 用戶端工具 | 用於管理存取權的主要介面、CLI 工具和 API。 | GDC 控制台、gdcloud CLI 和 KRM API。 | Google Cloud 控制台、gcloud CLI 和 REST 或 gRPC API。 |
| 直接存取 API | 工具和指令碼如何進行驗證，以便直接使用 API 管理資源。 | 如要使用 kubectl CLI 直接存取 API，必須產生 kubeconfig 檔案，向託管該資源的特定 Kubernetes 叢集或 API 伺服器進行驗證。(GDC 控制台和 gdcloud CLI 會自動連線至資源)。 |
使用 gcloud 或 REST/gRPC 端點直接存取 API 時，會使用集中式憑證 (gcloud auth login)，適用於所有服務，不需登入特定叢集。 |
後續步驟
- 如要連結貴組織的登入系統，請參閱「連結至識別資訊提供者」。
- 如要登入環境，請參閱「登入」。
- 如要授予權限及管理角色繫結，請參閱「授予及撤銷存取權」。