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 and Cluster node machines |
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 and CIS Kubernetes Benchmark |
| VM Secure Boot and OS management | Securely boot a VM and Manage OS packages |
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:
- 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:
For more information, see the following documentation:
| Topic | Documentation and configuration guides |
|---|---|
| Resource hierarchy and projects | Resource hierarchy and Manage projects |
| Kubernetes clusters | Kubernetes clusters in GDC and Cluster configurations |
| Boundary and workload design | Design access boundaries and Design workload separation |
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 and Create and manage Harbor resources |
| Workloads and services | Container workloads in GDC and Deploy Marketplace services |
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 KubernetesNetworkPolicyresources.
For more information, see the following documentation:
| Topic | Documentation and configuration guides |
|---|---|
| Perimeter and threat prevention | Networking overview, Request threat prevention, and Egress control |
| Network policies and flow logs | Organization network policies, Project network policies, Configure Kubernetes network policies, and Manage flow logs |
| External connectivity | Configure GDC VPN and Establish connectivity with interconnects |