授權和存取權控管

Google Distributed Cloud (GDC) air-gapped 中的 Identity and Access Management (IAM) 可讓您控管誰有權存取哪些資源，以及可對這些資源執行哪些操作。

瞭解 GDC 中的 IAM 運作方式，有助於有效管理存取權，確保成員擁有執行角色所需的權限，同時維護與網際網路隔離環境的安全。

本文件適用於平台管理員和應用程式操作人員群組 (例如 IT 管理員、安全工程師或應用程式開發人員) 的對象，協助他們瞭解 Google Distributed Cloud 實體隔離方案中的授權和存取控管。本文也有助於基礎架構營運人員建立存取控管概念的基礎知識。詳情請參閱 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 提供完整的預先定義角色程式庫，可根據特定工作職能和服務量身打造 (從專案檢視者等廣泛角色，到 Bucket 專案管理員或 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)，不需要登入特定叢集。

後續步驟