다음 설계가 권장되지만, 정확히 규정된 대로 따르지 않아도 됩니다. 각 GDC 유니버스에는 사례별로 충족해야 하는 고유한 요구사항과 고려사항이 있습니다.
조직별 ID 공급업체 구성
사업자는 조직당 하나 이상의 ID 공급업체를 구성해야 합니다. 그런 다음 관리자가 ID 공급업체에 연결하여 GDC 유니버스에 있는 애플리케이션의 인증 서비스를 관리합니다.
회사에 별도의 조직이 있는 여러 부서가 있고 각 조직이 인증을 위해 동일한 ID 제공업체에 연결되는 시나리오가 있을 수 있습니다. 이 경우 사용자가 여러 조직에서 보유한 권한의 조합을 이해하고 감사해야 합니다. 여러 조직의 권한이 있는 사용자가 워크로드를 별도의 조직으로 분리하는 요구사항을 위반하지 않도록 합니다.
또는 여러 공급업체 팀이 단일 조직에서 함께 작업하는 경우와 같이 서로 다른 사용자 집합이 서로 다른 ID 공급업체를 사용하여 단일 조직 내에서 인증하는 시나리오가 있을 수 있습니다. 사용자 ID를 단일 ID 공급업체로 통합할지 아니면 별도의 ID 공급업체를 유지할지 회사의 ID 관리 접근 방식에 따라 고려하세요.
ID 공급업체의 다중 인증 구성
GDC는 다중 인증과 같은 추가 보안 설정을 포함한 인증을 위해 IAM 플랫폼을 사용합니다. 민감한 리소스에 액세스할 수 있는 모든 사용자에 대해 실제 키로 다중 인증을 구성하는 것이 좋습니다.
관리 서비스 및 Marketplace 서비스 제한
프로젝트의 잠재적 공격 범위를 제한하거나 승인되지 않은 서비스의 사용을 방지하기 위해 특정 서비스에서 일부 프로젝트를 차단하는 것이 좋습니다.
기본적으로 인공 지능 및 머신러닝과 같은 관리형 서비스는 모든 프로젝트에서 사용할 수 있습니다. 관리형 서비스와 달리 Marketplace 서비스는 먼저 조직에 대해 사용 설정해야 합니다.
프로젝트에서 서비스 액세스를 거부하려면 서비스의 맞춤 리소스 정의와 네임스페이스 목록에 대해 Gatekeeper 제약 조건을 적용합니다. Gatekeeper로 액세스를 거부하는 방식은 관리 서비스와 Marketplace 서비스에 모두 적용됩니다.
여러 클러스터의 kubeconfig 파일 관리
다양한 운영 작업에는 서로 다른 클러스터에 대한 연결이 필요합니다. 예를 들어 IAM 역할을 프로젝트에 바인딩하는 작업과 Kubernetes 클러스터에 Kubernetes Pod 리소스를 배포하는 작업을 실행합니다.
GDC 콘솔을 사용하는 경우 기본 클러스터가 작업을 수행하는지 알 필요가 없습니다. GDC 콘솔은 클러스터에 연결하는 것과 같은 하위 수준 작업을 추상화하기 때문입니다.
하지만 gdcloud CLI 또는 kubectl CLI를 사용할 때는 작업을 완료하기 위해 kubeconfig 파일이 여러 개 있을 수 있습니다. 작업에 적합한 클러스터의 kubeconfig 사용자 인증 정보를 사용하여 로그인해야 합니다.
Kubernetes 서비스 계정 권장사항
Kubernetes 서비스 계정의 경우 승인은 보안 비밀 토큰을 기반으로 합니다. 서비스 계정 토큰의 위험을 완화하려면 다음 권장사항을 고려하세요.
expirationSeconds 필드를 워크로드의 서비스 계정 토큰 프로젝션에 대한 짧은 기간으로 설정합니다.
서비스 계정 사용자 인증 정보를 정기적으로 순환합니다.
최소 권한의 원칙 고려
사용자에게 역할 바인딩을 부여할 때는 최소 권한의 원칙 (PoLP)을 고려하세요. PoLP에 따라 작업을 완료하는 데 필요한 권한만 할당하는 것이 좋습니다.
예를 들어 사용자가 해당 프로젝트 내에서 역할을 부여할 권한을 위임할 수 있도록 단일 프로젝트 내에서 프로젝트 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."]]
