事業者は、組織ごとに 1 つ以上の ID プロバイダを構成する必要があります。管理者は、ID プロバイダに接続して、GDC ユニバースのアプリケーションの認証サービスを管理します。
会社に複数の部門があり、それぞれが個別の組織を持ち、各組織が同じ ID プロバイダに接続して認証を行うシナリオが考えられます。この場合、ユーザーが組織全体で持つ権限の組み合わせを把握し、監査するのはユーザーの責任です。複数の組織で権限を持つユーザーが、ワークロードを個別の組織に分離するための要件に違反しないようにします。
また、複数のベンダーチームが 1 つの組織内で連携している場合など、異なるユーザーセットが異なる ID プロバイダを使用して 1 つの組織内で認証を行うシナリオもあります。ユーザー ID を単一の ID プロバイダに統合するか、個別の ID プロバイダを維持するかが、会社の ID 管理アプローチに最適かどうかを検討します。
ID プロバイダの多要素認証を構成する
GDC は、多要素認証などの追加のセキュリティ設定を含む認証に IAM プラットフォームを使用します。機密リソースにアクセスする可能性のあるユーザーに対しては、物理キーを使用した多要素認証を構成することをおすすめします。
マネージド サービスとマーケットプレイス サービスを制限する
プロジェクトの潜在的な攻撃対象領域を制限したり、承認されていないサービスの使用を回避したりするために、特定のサービスから一部のプロジェクトをブロックすることが望ましい場合があります。デフォルトでは、AI や ML などのマネージド サービスは、どのプロジェクトでも使用できます。マネージド サービスとは異なり、マーケットプレイス サービスはまず組織に対して有効にする必要があります。
たとえば、単一のプロジェクト内でプロジェクト IAM 管理者のロールをユーザーに付与し、そのユーザーがプロジェクト内でロールを付与する権限を委任できるようにします。このユーザーは、使用する特定のサービスに基づいて、プロジェクト内の他のデベロッパーにきめ細かいロールを付与します。プロジェクト IAM 管理者のロールは、信頼できるリードに制限する必要があります。このロールは、権限を昇格させ、プロジェクトで自分自身または他のユーザーに追加のロールを付与するために使用される可能性があるためです。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[[["\u003cp\u003eThis document provides best practices for permissioning design in a Google Distributed Cloud (GDC) air-gapped environment, covering topics like identity providers, multi-factor authentication, and service management.\u003c/p\u003e\n"],["\u003cp\u003eIt's recommended to configure at least one identity provider per organization, and multi-factor authentication should be enabled, especially for users who access sensitive resources.\u003c/p\u003e\n"],["\u003cp\u003eAdministrators can restrict managed and marketplace services to limit the attack surface and ensure only approved services are in use, by applying Gatekeeper constraints.\u003c/p\u003e\n"],["\u003cp\u003eWhen using the \u003ccode\u003egdcloud\u003c/code\u003e or \u003ccode\u003ekubectl\u003c/code\u003e CLIs, users should manage kubeconfig files carefully, ensuring the correct cluster credentials are used for the task at hand.\u003c/p\u003e\n"],["\u003cp\u003eOrganizations should adhere to the principle of least privilege when granting roles, and regularly audit permissions to avoid excessive privileges and potential security risks.\u003c/p\u003e\n"]]],[],null,["# Design permissioning setup\n\nThis document outlines best practices for permissioning design in a\nGoogle Distributed Cloud (GDC) air-gapped universe. The following topics are covered:\n\n- [Identity providers (IdP) per organization](#configure-idp-per-org)\n- [Multi-factor authentication for IdPs](#configure-multi-factor-auth-for-idp)\n- [Managed and marketplace services](#restrict-managed-marketplace-services)\n- [Cluster kubeconfig management](#manage-kubeconfig-for-multiple-clusters)\n- [Kubernetes service accounts](#best-practices-kub-service-accounts)\n- [Principle of least privilege](#principle-of-least-privilege)\n- [Regular audits for excess privilege](#audit-regularly)\n\nAlthough the following designs are recommended, it's not required to follow them\nexactly as prescribed. Each GDC universe has unique\nrequirements and considerations that must be satisfied on a case-by-case basis.\n\nConfigure an identity provider per organization\n-----------------------------------------------\n\nAn operator must configure one or more identity providers per organization. An\nadministrator then\n[connects to an identity provider](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/iam/connect-identity)\nto manage authentication services for applications in the\nGDC universe.\n\nYou might have a scenario where your company has multiple departments with\nseparate organizations, and each organization connects to the same identity\nprovider for authentication. In that case, it is your responsibility to\nunderstand and audit the combination of privileges a user has across\norganizations. Ensure that a user with privileges in multiple organizations does\nnot violate the requirements for separating workloads into distinct\norganizations.\n\nAlternatively, you might have a scenario where different sets of users use\ndifferent identity providers to authenticate within a single organization, such\nas when multiple vendor teams work together in a single organization. Consider\nwhether consolidating user identities into a single identity provider or\nmaintaining separate identity providers works best with your company's approach\nto identity management.\n\nConfigure multi-factor authentication for your identity provider\n----------------------------------------------------------------\n\nGDC relies on your IAM platform for\nauthentication, including additional security settings such as multi-factor\nauthentication. It is good practice to configure multi-factor authentication\nwith a physical key for any user that might potentially access sensitive\nresources.\n\nRestrict managed services and marketplace services\n--------------------------------------------------\n\nYou might prefer to block some projects from certain services, to either limit\nthe potential attack surface in a project or avoid use of unapproved services.\nBy default, managed services like Artificial Intelligence and Machine Learning\nare available to use in any project. In comparison to managed services,\nmarketplace services must first be enabled for the organization.\n\nTo deny service access from projects, apply\n[Gatekeeper constraints](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/org-policy) against the\ncustom resource definition of a service and a list of namespaces. The approach\nto deny access with Gatekeeper applies to managed and marketplace services.\n\nManage kubeconfig files for multiple clusters\n---------------------------------------------\n\nDifferent operational tasks require a connection to different clusters. For\nexample, you perform tasks like binding an IAM role to a project,\nand tasks like deploying a Kubernetes `Pod` resource on a Kubernetes cluster.\n\nWhen using the GDC console, you don't need to be aware of which\nunderlying cluster performs a task, as the GDC console abstracts away\nthe low-level operations like connecting to a cluster.\n\nHowever, when working with the gdcloud CLI or kubectl CLI, you\nmight have multiple kubeconfig files for accomplishing your tasks. Ensure that\nyou [sign in](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/iam/sign-in#cli) using kubeconfig\ncredentials for the appropriate cluster for your task.\n\nBest practices for Kubernetes service accounts\n----------------------------------------------\n\nFor Kubernetes service accounts, authorization is based on a secret token. To\nmitigate the risk of service account tokens, consider the following best\npractices:\n\n- Avoid downloading persistent service account credentials for use outside of GDC.\n- Be aware of [Kubernetes escalation paths](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#privilege-escalation-via-pod-creation) for users or service accounts who have the ability to create and edit pods.\n- Set the `expirationSeconds` field to a short time period for the service account token projection of your workloads.\n- Regularly rotate service account credentials.\n\nConsider principle of least privilege\n-------------------------------------\n\nConsider the principle of least privilege (PoLP) when granting\n[role bindings](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/iam/set-up-role-bindings) to\nusers. In accordance with PoLP, consider assigning only privileges required to\ncomplete a task.\n\nFor example, you grant the Project IAM Admin role within a single project to a\nuser, so that this user delegates authority to grant roles within that project.\nThis user then grants granular roles to other developers in the project based on\nthe specific services they use. The Project IAM Admin role must be restricted to\na trusted lead because this role could be used to escalate privilege, granting\noneself or others additional roles in the project.\n\nAudit regularly for excessive privileges\n----------------------------------------\n\nBe sure to review roles granted within your organization and audit against\nexcessive privilege. You must ensure that the roles granted are necessary for an\nindividual user to complete their job, and that combinations of roles across\nprojects don't lead to an escalation or exfiltration risk.\n\nIf your company uses multiple organizations, we don't recommend that an\nindividual user has highly privileged roles across multiple organizations, as\nthis might violate the reason for separating organizations in the first place."]]
