This document provides an overview for how projects work in Google Distributed Cloud (GDC) air-gapped. A project is a collection of your resources. Projects help to segment resources within your organization and provide a boundary for managing resource lifecycles and enforcing policies. When a project is deleted, all resources within it are also deleted, and policies that apply to a project also apply to all the resources in the project. You can use projects to organize and manage your resources as a group. For more information, see Resource hierarchy.
This document is for audiences such as IT administrators, security engineers, and network administrators within the platform administrator group who are responsible for managing resources within their organization. For more information, see Audiences for GDC air-gapped documentation.
Project identifiers
A project has two identifiers:
Project name: A human-readable name for your project. The project name isn't used by GDC APIs. You can edit the project name at any time during or after project creation. Project names don't need to be unique.
Project ID: A globally unique identifier for your project. A project ID is a unique string used to differentiate your project in GDC. The project ID is generated by the system when you create a project, and it cannot be modified after the project is available. The namespaces propagated by a project are the same as the project ID.
Don't include sensitive information in your project name, project ID, or other resource names. The project ID is used in the name of many other GDC resources, and any reference to the project or related resources exposes the project ID and resource name.
Project namespace
The namespace for a project hosts several resources and configurations, such as:
- Project-scoped service APIs or Kubernetes custom resource definitions.
- Project-level policy configurations, such as roles and role bindings.
A project is considered a Kubernetes namespace that can span multiple shared Kubernetes clusters in an organization. A shared cluster is a Kubernetes cluster that can attach to multiple projects, whereas a standard cluster is a Kubernetes cluster that operates within a single project namespace. For more information about Kubernetes clusters in GDC, see Kubernetes cluster configurations.
Kubernetes treats each shared cluster as a separate entity, and each shared cluster has an independent project namespace. However, for all shared clusters in a GDC organization, GDC considers all namespaces with the same name to be the same namespace. This is referred to as namespace sameness. The single namespace has a consistent owner across the set of shared clusters. Service providers create project-scoped services by creating control plane and data plane components in the namespace.
This diagram illustrates namespace sameness across three shared clusters, each
for container workloads corresponding to the development lifecycle of an
organization. There are two project namespaces backend and frontend that
provide namespaces that span across the clusters. Although a project namespace
is replicated across multiple shared clusters, it's recognized as a single
namespace with consistent permissions and characteristics.