Google Distributed Cloud (GDC) air-gapped helps protect hardware racks, host operating
systems, multi-tenant boundaries, software supply chains, and network traffic
deployed in accredited data center facilities.

## Facility security

GDC hardware is deployed inside accredited data center
facilities controlled by you or your designated facility operator. Your
organization and the infrastructure operator are responsible for enforcing
physical access controls, environmental protections, and media handling
procedures for the facility hosting the GDC racks.

Recommended physical security controls include the following:

- **Perimeter and rack access controls**: restrict physical entry to the data center and GDC racks using badge readers, biometric authentication, visitor escort logs, 24/7 security guard patrols, and locked rack doors.
- **Surveillance and tamper detection**: monitor rack aisles with continuous closed-circuit television (CCTV) and physical intrusion alarms.
- **Power, cooling, and cabling isolation**: provide redundant power feeds, environmental monitoring, and protected cabling pathways that meet your regulatory and accreditation requirements (such as ISO/IEC 27001 or ICD 705).

## Hardware security

GDC runs on pre-integrated, modular hardware racks
manufactured with commercial-off-the-shelf (COTS) components from vetted
original equipment manufacturers (OEMs). Certified regional facilities staffed
by background-checked personnel integrate the hardware racks. High-risk hardware
and firmware components also undergo dedicated security reviews against supply
chain and physical tampering threats.

Key hardware security controls include the following:

- **Compute servers**: bare-metal servers use hardware roots of trust, trusted platform modules (TPM 2.0), and signed baseboard management controller (BMC) firmware to verify hardware and boot integrity before loading the operating system.
- **Network switches and perimeter firewalls**: top-of-rack and management switches enforce port-level access controls and MACsec encryption. Redundant perimeter firewalls provide line-rate stateful inspection and intrusion prevention at the zone boundary.
- **Storage appliances**: enterprise block, file, and object storage appliances enforce hardware-accelerated AES-256 encryption at rest on self-encrypting drives (SEDs) and logical tenant isolation through dedicated storage virtual machines (SVMs).
- **Hardware security modules (HSMs)**: dedicated network-attached HSM appliances (FIPS 140-2 Level 3 and FIPS 140-3 validated) generate, store, and protect root cryptographic keys in tamper-evident hardware.

For more information, see the following documentation:

| Topic | Documentation and configuration guides |
|---|---|
| **Hardware and HSM management** | [Control HSM keys](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/hsm.md.txt) and [Cluster node machines](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/cluster-node-machines.md.txt) |

## Host and node security

Every bare-metal host and Kubernetes cluster node in GDC
runs a hardened operating system image configured to minimize the attack surface
and prevent unauthorized privilege escalation.

- **STIG-hardened operating system**: nodes run Linux hardened against Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs) and Center for Internet Security (CIS) benchmarks. Unnecessary packages, compilers, and network services are removed from the base image.
- **UEFI Secure Boot**: both bare-metal hosts and user virtual machines (VMs) support UEFI Secure Boot to verify that only cryptographically signed bootloaders and kernel images run during startup.
- **Kernel and mandatory access controls**: nodes enforce SELinux in enforcing mode, seccomp system call filtering, Linux namespaces, and cgroups resource limits to isolate containers from the underlying host kernel.
- **Host integrity and endpoint protection**: file integrity monitoring (FIM) checks critical system files for unauthorized changes, and endpoint detection and response (EDR) and anti-malware controls monitor process execution and host telemetry.

For more information, see the following documentation:

| Topic | Documentation and configuration guides |
|---|---|
| **Node isolation and benchmarks** | [Node isolation overview](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/node-isolation-overview.md.txt) and [CIS Kubernetes Benchmark](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/reference/cis-benchmarks.md.txt) |
| **VM Secure Boot and OS management** | [Securely boot a VM](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/application/ao-user/vms/manage-vms/secure-vms/secure-boot.md.txt) and [Manage OS packages](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/application/ao-user/vms/manage-the-os/manage-os-packages.md.txt) |

## Tenancy

GDC provides hierarchical multi-tenancy with both hard
physical and network isolation between organizations and logical namespace
isolation between projects within an organization.

### Logical isolation across organizations, clusters, and projects

The following diagram shows how the root admin cluster, org infrastructure
clusters, and workload clusters are isolated across management and tenant
boundaries:

![A diagram of a GDC root admin cluster, org infrastructure clusters, and workload clusters.](https://docs.cloud.google.com/static/distributed-cloud/hosted/docs/1.16/gdcag/images/tenancy-between-orgs-proj-clusters.png)

- **Root admin cluster**: dedicated to bootstrapping organizations, managing hardware inventory, and running infrastructure security and observability services.
- **Organization**: the top-level tenant boundary. Each organization has its own dedicated org infrastructure cluster, identity provider configuration, Key Management System (KMS) hierarchy, and virtual routing and forwarding (VRF) instance.
- **Kubernetes clusters** : you can provision organization-scoped **shared
  clusters** (which host multiple projects) or project-scoped **standard
  clusters** (dedicated to a single project for stronger workload separation).
- **Project**: a logical tenancy unit within an organization where you deploy VMs, containers, databases, and storage resources. Projects enforce Kubernetes namespace sameness, role-based access control (RBAC) boundaries, and project network policies across clusters.

### Physical and VRF isolation across racks

Across physical 42U racks, GDC isolates organizations
onto separate compute servers, storage virtual machines (SVMs), and network VRFs
so no physical compute servers are shared between organizations:

![A diagram showing physical compute, storage appliance, and VRF isolation across GDC racks.](https://docs.cloud.google.com/static/distributed-cloud/hosted/docs/1.16/gdcag/images/tenancy-operator-layers.png)

For more information, see the following documentation:

| Topic | Documentation and configuration guides |
|---|---|
| **Resource hierarchy and projects** | [Resource hierarchy](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/resources/resource-hierarchy.md.txt) and [Manage projects](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/project-management.md.txt) |
| **Kubernetes clusters** | [Kubernetes clusters in GDC](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/clusters.md.txt) and [Cluster configurations](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/cluster-configs.md.txt) |
| **Boundary and workload design** | [Design access boundaries](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/resources/access-boundaries.md.txt) and [Design workload separation](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/resources/workload-separation.md.txt) |

## Application security

GDC secures both platform software delivered across the
air gap and customer applications deployed inside your organization.

### Software supply chain and SLSA validation

All GDC platform components, first-party services, and
managed third-party services are built in isolated, hermetic build environments
and scanned for vulnerabilities. Artifacts are signed on the connected side
("low side") in compliance with Supply-chain Levels for Software Artifacts
(SLSA) requirements before transfer across the air gap ("high side").

Each release includes a software bill of materials (SBOM) detailing software
components, dependencies, and libraries, and artifacts are verified using
cryptographic signatures and SHA-256 checksums before deployment.

### Artifact registry and policy enforcement

GDC enforces container image and policy controls before
deployment:

- **Local artifact registry (Harbor)**: container images and Helm charts are stored in a local Harbor registry inside the air-gapped environment, supporting image signing and vulnerability scanning without external internet access.
- **Admission control and organization policies**: Open Policy Agent (OPA) Gatekeeper enforces organization policies on Kubernetes clusters, preventing pods from running with privileged escalation, host network access, or untrusted container images.

For more information, see the following documentation:

| Topic | Documentation and configuration guides |
|---|---|
| **Policies and artifact registry** | [Configure organization policies](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/org-policy.md.txt) and [Create and manage Harbor resources](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform-application/pa-ao-operations/mhs-overview.md.txt) |
| **Workloads and services** | [Container workloads in GDC](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/application/ao-user/containers/containers-intro.md.txt) and [Deploy Marketplace services](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/application/ao-user/marketplace-overview.md.txt) |

## Network security

GDC enforces multi-layered network segmentation from
physical switch ports up to Layer 7 service mesh policies.

### Data-plane VRF and VXLAN segmentation

The data-plane fabric uses Multiprotocol BGP (MP-BGP) Ethernet VPN (EVPN) with
Virtual Extensible LAN (VXLAN) encapsulation to isolate traffic between the root
admin cluster and each tenant organization.

- **Out-of-band (OOB) management network**: hardware management interfaces operate on a physically separate management network isolated from tenant traffic and accessible only from the root admin cluster.
- **VRF and VXLAN isolation**: each organization is assigned dedicated Layer 3 Virtual Network Identifiers (VNIs), external and internal VRFs, and isolated storage virtual machines (SVMs) so tenant traffic can't cross organization boundaries without explicit firewall traversal.
- **Next-generation firewall, IDPS, and denial-of-service (DoS) protection**: perimeter firewalls and intrusion detection and prevention systems (IDPS) enforce a default-deny posture, inspect inbound and outbound traffic against threat signatures, and work with load balancers to throttle session floods. Firewall and IDPS logs integrate with the organization's observability stack and infrastructure security monitoring.
- **Project and Kubernetes network policies** : within an organization, you can enforce default-deny microsegmentation between projects and pods using `ProjectNetworkPolicy`, `OrganizationNetworkPolicy`, and Cilium-backed Kubernetes `NetworkPolicy` resources.

For more information, see the following documentation:

| Topic | Documentation and configuration guides |
|---|---|
| **Perimeter and threat prevention** | [Networking overview](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/networking-overview.md.txt), [Request threat prevention](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/request-security.md.txt), and [Egress control](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/data-exfiltration.md.txt) |
| **Network policies and flow logs** | [Organization network policies](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/org-network-policy.md.txt), [Project network policies](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/pnp/pnp-overview.md.txt), [Configure Kubernetes network policies](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/k8s-network-policy/k8s-network-policy-overview.md.txt), and [Manage flow logs](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/flow-logs.md.txt) |
| **External connectivity** | [Configure GDC VPN](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/vpn/gdc-vpn-overview.md.txt) and [Establish connectivity with interconnects](https://docs.cloud.google.com/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/interconnects/interconnect-overview.md.txt) |