本頁面由 Cloud Translation API 翻譯而成。

設定設計權限

本文說明 Google Distributed Cloud (GDC) 實體隔離環境中，權限設計的最佳做法。本文涵蓋下列主題：

雖然建議採用下列設計，但不必完全按照規定。每個 GDC 宇宙都有獨特的需求和考量，必須逐一滿足。

為每個機構設定識別資訊提供者

每個機構都必須設定一或多個識別資訊提供者。接著，管理員會連線至識別資訊提供者，管理 GDC 領域中應用程式的驗證服務。

假設貴公司有多個部門，每個部門都有各自的機構，且每個機構都連線至同一個身分提供者進行驗證。在這種情況下，您有責任瞭解及稽核使用者在各機構擁有的權限組合。確認在多個機構中擁有權限的使用者，不會違反將工作負載劃分為不同機構的規定。

或者，您可能遇到不同組使用者在單一機構內使用不同身分識別提供者進行驗證的情況，例如多個供應商團隊在單一機構內合作時。請考量將使用者身分整合至單一身分識別提供者，或是維持個別身分識別提供者，哪種做法最符合貴公司的身分管理方式。

GDC 會依賴 IAM 平台進行驗證，包括多重驗證等額外安全設定。建議為可能存取機密資源的所有使用者，設定使用實體金鑰的多重驗證。

您可能偏好禁止某些專案使用特定服務，藉此限制專案中潛在的攻擊面，或避免使用未經核准的服務。根據預設，任何專案都能使用人工智慧和機器學習等代管服務。與代管服務相比，機構必須先啟用 Marketplace 服務。

如要拒絕專案存取服務，請對服務的自訂資源定義和命名空間清單套用 Gatekeeper 限制。使用 Gatekeeper 拒絕存取權的方法適用於受管理和市集服務。

不同的作業工作需要連線至不同的叢集。舉例來說，您可以執行將 IAM 角色繫結至專案的工作，以及在 Kubernetes 叢集上部署 Kubernetes Pod 資源的工作。

使用 GDC 控制台時，您不需要瞭解哪個基礎叢集執行工作，因為 GDC 控制台會抽象化低層級作業，例如連線至叢集。

不過，使用 gdcloud CLI 或 kubectl CLI 時，您可能需要多個 kubeconfig 檔案才能完成工作。請務必使用工作適用的叢集，透過 kubeconfig 憑證登入。

如果是 Kubernetes 服務帳戶，授權會以密鑰權杖為依據。為降低服務帳戶權杖的風險，請考慮採用下列最佳做法：

授予使用者角色繫結時，請考慮最低權限原則 (PoLP)。請根據 PoLP，只指派完成工作所需的權限。

舉例來說，您可以在單一專案中授予使用者專案 IAM 管理員角色，讓該使用者委派權限，在該專案中授予角色。然後，這個使用者會根據專案中其他開發人員使用的特定服務，授予細部角色。專案 IAM 管理員角色必須僅限於信任的領導者，因為這個角色可用於提升權限，在專案中授予自己或其他使用者額外角色。

請務必檢查貴機構授予的角色，並稽核過多的權限。您必須確保授予的角色是個別使用者完成工作所需的角色，且專案中的角色組合不會導致權限提升或資料外洩風險。

如果貴公司使用多個機構，我們不建議個別使用者在多個機構中擁有高權限角色，因為這可能會違反當初區隔機構的原因。