[[["容易理解","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 (世界標準時間)。"],[[["\u003cp\u003eOrganizations in Google Distributed Cloud (GDC) air-gapped provide physical and logical isolation for compute, networking, and storage, ensuring users in one organization cannot access resources in another without explicit permission.\u003c/p\u003e\n"],["\u003cp\u003eProjects within an organization offer logical separation for workloads through Identity and Access Management (IAM) and network policies, enabling the sharing of resources like role bindings and observability requirements among them.\u003c/p\u003e\n"],["\u003cp\u003eWorkloads can be grouped into a single organization if they share dependencies, administrative trust, physical infrastructure, budget accountability, and high availability requirements.\u003c/p\u003e\n"],["\u003cp\u003eProjects should be created for different deployment environments, such as production and development, to enable granular role bindings and network policies, preventing development changes from impacting production environments.\u003c/p\u003e\n"],["\u003cp\u003eKubernetes clusters have a many-to-many relationship with projects, allowing multiple clusters in a project or a single cluster spanning multiple projects, while access controls are primarily managed at the project level.\u003c/p\u003e\n"]]],[],null,["# Design access boundaries between resources\n\nThis document introduces best practices for designing the hierarchy and\nseparation for workloads in Google Distributed Cloud (GDC) air-gapped using organizations,\nprojects, and Kubernetes clusters. This guidance balances efficient resource\nusage, isolation of workloads, and ease of operations.\n\nDesign organizations for physical and logical isolation between customers\n-------------------------------------------------------------------------\n\nThe `Organization` resource is the root for all the resources owned by a single\ncustomer. Granular access control between workloads within an organization can\nbe defined through role bindings and network policies. See\n[Identity and access management](/distributed-cloud/hosted/docs/latest/gdch/application/ao-user/iam/sign-in) for more\ninformation.\n\nEach organization within a GDC zone provides physical\nisolation for compute infrastructure, and logical isolation for networking,\nstorage, and other services. Users in one organization have no access to\nresources in another organization unless explicitly granted access. Network\nconnectivity from one organization to another is not allowed by default, unless\nexplicitly configured to allow data transfer out from one organization and data\ntransfer in to another.\n\nDefine the scope of workloads that can share an organization\n------------------------------------------------------------\n\nThe scope of an organization in your company context might vary based on how\nyour company defines trust boundaries. Some companies might prefer to create\nmultiple organization resources for different entities in the company. For\nexample, each company department might be an independent customer of\nGDC with an independent organization if the departments\nrequire complete physical and administrative separation of their workloads.\n\nIn general, we recommend that you group multiple workloads into a single\norganization based on the following signals:\n\n- Workloads can share dependencies. For example, this might be a shared data source, connectivity between workloads, or a shared monitoring tool.\n- Workloads can share an administrative root of trust. The same administrator can be trusted with privileged access over all workloads in the organization.\n- Workloads are allowed to share underlying physical infrastructure with other workloads in the same organization, as long as sufficient logical separation is in place.\n- The same budget holder has accountability for workload budgets in aggregate. For details on viewing aggregate costs for the organization or granular analysis per workload, see the [Billing](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/billing/manage-billing-accounts) page.\n- Workload availability requirements must follow your high availability requirements for multi-zone distance.\n\nDesign projects for logical isolation between workloads\n-------------------------------------------------------\n\nWithin an organization, we recommend provisioning multiple projects to create a\nlogical separation between resources. Projects in the same organization might\nshare the underlying physical infrastructure, but projects are used to separate\nworkloads with a logical boundary based on Identity and Access Management (IAM) policies\nand network policies.\n\nWhen designing project boundaries, think of the largest set of\nfunctionality that can be shared by resources, such as\n[role bindings](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/iam/set-up-role-bindings),\n[network policies](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/configure-pnp#security-and-connectivity), or\n[observability](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/monitoring-overview)\nrequirements. Group the resources that can share this functionality into a\nproject, and move resources that cannot share this functionality to another\nproject.\n\nIn Kubernetes terms, a project is a Kubernetes *namespace* that is reserved\nacross all clusters in an organization. Though a namespace is reserved across\nmultiple clusters, that does not mean a pod is automatically scheduled across\nall clusters. A pod scheduled to a particular cluster remains scheduled to that\nparticular cluster.\n\nThe following diagram shows how a role binding is applied to a project\nthat spans multiple clusters.\n\nRole bindings are set at the project level to define who can do what to\nwhich resource type. Workloads like VMs or pods are deployed to a project,\nand access to these workloads is governed by the role binding. The role binding\napplies consistently to VM-based workloads and container-based workloads,\nregardless of which cluster they are deployed to.\n\nThe following diagram shows how network policies manage access between projects.\nInter-project communication between the `Backend Project`, `Frontend Project`,\nand `Database Project` is disabled. However, resources within each project can\ncommunicate with each other.\n\n[Network policies](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/configure-pnp#security-and-connectivity)\nare set at the project level to selectively allow network\naccess between resources. By default, all resources within a single project are\nallowed to communicate with each other on the internal network, and a resource\nin one project cannot communicate with a resource in another project. This\nbehavior for network policies applies whether resources are deployed to the\nsame cluster or not.\n\nYou can also define a `ProjectNetworkPolicy` custom resource to enable\ninter-project communication. This policy is defined for each project to allow\ningress traffic from other projects. The following diagram illustrates a\n`ProjectNetworkPolicy` custom resource defined for the `Backend Project` to\nenable data transfer in from the `Frontend Project` and `Database Project`.\n\nAdditionally, the\n[monitoring](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/monitoring-overview)\nstack collects metrics across the organization, but you can\nfilter and query at various levels of the resource hierarchy. You can query\nmetrics with entities such as a cluster or namespace.\n\nCreate projects per deployment environment\n------------------------------------------\n\nFor each workload, we recommend creating separate projects for production,\ndevelopment, and any other deployment environments you require. Separating your\nproduction and development deployment environments lets you define role\nbindings and network policies granularly, so that changes made in a\nproject used for development don't impact the production environment.\n\nGrant resource-level role bindings within projects\n--------------------------------------------------\n\nDepending on your team structure and requirements, you might allow developers to\nmodify any resource within the project they manage, or you might require more\ngranular access control. Within a project, you grant granular role bindings to\nlet individual developers access to some but not all resources in the project. For\nexample, a team might have a database administrator who must manage the database\nbut not modify other resources, while the software developers on the team must not\nhave permission to modify the database.\n\nDesign clusters for logical isolation of Kubernetes operations\n--------------------------------------------------------------\n\nA Kubernetes cluster is not a hard tenant boundary because\n[role bindings](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/iam/set-up-role-bindings) and\n[network policies](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/configure-pnp#security-and-connectivity)\napply to projects, not Kubernetes clusters. Kubernetes clusters and\nprojects have a many-to-many relationship. You might have multiple Kubernetes clusters\nin a single project, or a single Kubernetes cluster that spans multiple projects."]]
