本文概述在 Google Distributed Cloud (GDC) 實體隔離環境中設計權限的最佳做法。涵蓋的主題如下：
雖然我們建議採用下列設計，但您不一定要完全按照規定。每個 GDC 宇宙都有獨特的需求和考量，必須視情況滿足。
為每個組織設定識別資訊提供者
操作員必須為每個組織設定一或多個識別資訊提供者。接著，管理員會連線至識別資訊提供者，管理 GDC 宇宙中應用程式的驗證服務。
貴公司可能有多個部門，每個部門都有獨立的組織，且每個組織都連結至同一個識別資訊提供者進行驗證。在這種情況下，您有責任瞭解及稽核使用者在各組織中的權限組合。確保在多個組織中擁有權限的使用者，不會違反將工作負載分隔至不同組織的要求。
或者，您可能遇到不同使用者使用不同 IdP 在單一組織內進行驗證的情況，例如多個供應商團隊在單一組織內合作。請考量將使用者身分整合至單一識別資訊提供者，或維護個別識別資訊提供者，是否最符合貴公司的身分管理方法。
為識別資訊提供者設定多重驗證
GDC 仰賴 IAM 平台進行驗證，包括多重驗證等額外安全性設定。建議您為可能存取機密資源的所有使用者，設定使用實體金鑰的多重驗證。
限制代管服務和市集服務
您可能想禁止某些專案使用特定服務，以限制專案的潛在攻擊面，或避免使用未經核准的服務。根據預設，任何專案都能使用人工智慧和機器學習等代管服務。與代管服務相比，Marketplace 服務必須先為組織啟用。
如要拒絕專案的服務存取權，請對服務的自訂資源定義和命名空間清單套用 Gatekeeper 限制。使用 Gatekeeper 拒絕存取的方法適用於代管和市集服務。
管理多個叢集的 kubeconfig 檔案
不同的作業工作需要連線至不同的叢集。例如，您可以執行將 IAM 角色繫結至專案等工作，以及在 Kubernetes 叢集上部署 Kubernetes Pod 資源等工作。
使用 GDC 控制台時，您不必知道哪個基礎叢集執行工作，因為 GDC 控制台會抽象化低階作業，例如連線至叢集。
不過，使用 gdcloud CLI 或 kubectl CLI 時，您可能會有多個 kubeconfig 檔案來完成工作。請務必使用 kubeconfig 憑證登入，並選擇適合您工作的叢集。
Kubernetes 服務帳戶的最佳做法
Kubernetes 服務帳戶的授權依據是 Secret 權杖。為降低服務帳戶權杖的風險，請考慮下列最佳做法：
- 避免下載永久服務帳戶憑證，以便在 GDC 以外使用。
- 請留意有權建立及編輯 Pod 的使用者或服務帳戶，是否具備 Kubernetes 權限升級路徑。
- 將
expirationSeconds欄位設為短時間範圍，用於工作負載的服務帳戶權杖投影。 - 定期輪替服務帳戶憑證。
考量最小權限原則
將角色繫結授予使用者時，請考量最小權限原則 (PoLP)。根據 PoLP，請考慮僅指派完成工作所需的權限。
舉例來說，您在單一專案中將 IAM 專案管理員角色授予使用者，讓該使用者委派權限，在該專案中授予角色。接著，這位使用者會根據專案中其他開發人員使用的特定服務，授予精細角色。IAM 專案管理員角色必須限制為信任的負責人，因為這個角色可用於提高權限，為自己或他人授予專案中的其他角色。
定期稽核，找出過多權限
請務必檢查組織內授予的角色，並稽核是否有過多權限。您必須確保授予的角色是個別使用者完成工作所必需，且跨專案的角色組合不會導致權限提升或外洩風險。
如果貴公司使用多個組織，我們不建議讓個別使用者在多個組織中擁有高權限角色，因為這可能違反當初區分組織的原因。