Regulated Compute Data and Network Controls

Network segmentation for regulatory adherence creates a data-plane boundary that keeps regulated data inside approved projects and networks. VPC Service Controls (opens in a new tab) is the service that forms this boundary around Google Cloud projects and Google Cloud APIs. The perimeter denies data movement across its boundary even when Identity and Access Management permissions would allow it, which prevents unauthorized exfiltration across regulated boundaries. A complete design pairs the perimeter with private communication pathways, restrictive egress firewall rules, and narrow ingress and egress exceptions.

1.1VPC Service Controls Perimeters as Regulatory Boundaries

VPC Service Controls perimeters as regulatory boundaries are API-level perimeters that govern data movement between protected projects and restricted Google Cloud APIs. The perimeter is defined inside an Access Context Manager access policy, which exists once per organization, and it lists protected projects in --resources and protected APIs in --restricted-services. In production, the design should restrict all supported services rather than only Cloud Storage (storage.googleapis.com) and Compute Engine (compute.googleapis.com), because any unrestricted API remains a potential exfiltration path.

A new perimeter for existing production workloads should first run in dry run mode and only then move to enforced mode. Dry run mode logs what would be denied without blocking traffic, so teams can discover legitimate dependencies before enforcement breaks them. The tutorial configuration enforces immediately only because no production resources are inside the perimeter. The perimeter also configures --vpc-allowed-services, and using the alias value RESTRICTED-SERVICES allows traffic from the Virtual Private Cloud (VPC) network to reach the same set of APIs defined as restricted services.

1.2Private Communication Pathways Inside the Perimeter

Private communication pathways inside the perimeter keep regulated traffic off the public internet by routing Google API calls through private IP addresses inside the VPC network. Private Google Access allows a subnet such as restricted-subnet (10.0.0.0/24) to reach Google APIs without external IP addresses, while Private Service Connect provides a private endpoint IP such as 10.0.1.1 that is bound to the vpc-sc bundle of APIs. Cloud DNS then redirects googleapis.com and *.googleapis.com queries inside restricted-vpc to that endpoint, so API data flows from the workload to the Private Service Connect endpoint instead of to public VIPs.

Building the private path inside the perimeter follows an ordered dependency:

1. Create the VPC network and subnet: Create restricted-vpc in custom subnet mode and create restricted-subnet with Private Google Access enabled.
2. Create the Private Service Connect endpoint: Reserve global address 10.0.1.1 for Private Service Connect in restricted-vpc and create a global forwarding rule with --target-google-apis-bundle=vpc-sc.
3. Redirect DNS to the endpoint: Create a private Cloud DNS zone for googleapis.com. attached to restricted-vpc, create an A record for googleapis.com to 10.0.1.1, and create a CNAME record for *.googleapis.com to googleapis.com.
4. Deny broad egress: Create low-priority firewall rule deny-all-egress with priority 65534 that denies all egress to 0.0.0.0/0.
5. Allow only the private endpoint: Create higher-priority rule allow-psc-for-google-apis with priority 1000 that allows egress on tcp:443 to 10.0.1.1.

Regional and multi-regional API endpoints (opens in a new tab) cannot use standard Private Google Access and must use Private Service Connect endpoints inside the VPC perimeter. For hybrid access over Cloud VPN or Cloud Interconnect, Cloud Router must advertise the private endpoint ranges with custom route advertisements, on-premises firewalls must allow outbound traffic to those ranges, and VPC egress firewall policies must allow traffic to the private IP addresses. Connections that still use public endpoints, including Integration Connectors (opens in a new tab) (connectors.googleapis.com) backends and non-Google Cloud destinations, fail after perimeter enforcement unless their destination is a Private Service Connect attachment.

1.3Firewall and Routing Controls for Egress Denial

Firewall and routing controls for egress denial are network-level rules that complement the API-level perimeter by blocking internet egress by default. The low-priority deny rule blocks all egress, including the default domains normally reachable with Private Google Access and the implied firewall rules, before the higher-priority allow rule selectively reopens tcp:443 to the Private Service Connect endpoint. Because firewall priority decides first, traffic flows from the virtual machine to 10.0.1.1 only when it matches the priority-1000 allow, and all other internet egress is denied by the priority-65534 deny.

This deny-by-default posture is what mitigates network egress paths to the internet for workloads inside the regulated network. Workloads can still resolve Google APIs to the private address because the Cloud DNS policy applies to restricted-vpc, and routing stays internal to the VPC. If default internet routes are removed, explicit routes must exist for any approved public VIP ranges with the next hop set to the default internet gateway, or traffic must use standard internal routing to Private Service Connect addresses.

1.4Perimeter Access Decisions for Inside and Outside Traffic

Perimeter access decisions for inside and outside traffic are evaluations made by the Service Control API on every API request. The Service Control API checks the source network, source project, and target resource project against the perimeter configuration. Requests from outside the perimeter, such as from Cloud Shell, are denied for restricted services even with sufficient Identity and Access Management privileges, while requests for unrestricted services such as Cloud Resource Manager may still succeed. Requests from inside the perimeter are allowed to restricted resources inside the same perimeter but are denied to restricted resources in outside projects, including public read-only buckets.

The resulting boundary behavior is:

VPC-accessible services further limit which APIs a network endpoint inside the perimeter can call. A Compute Engine instance and other in-network endpoints can only request services configured in that allowlist, so an omitted service is unreachable from the virtual machine even if the perimeter otherwise protects it. Serverless traffic or traffic originating outside the perimeter follows different enforcement paths, so preventing creation of an unapproved service requires a separate control.

1.5Ingress, Egress, and Access Level Exceptions

Ingress, egress, and access level exceptions are narrow, auditable holes in an otherwise closed perimeter for regulated operations. An egress policy names both sides of the exception: egressFrom identifies the source identity, such as the attached service account of demo-vm, and egressTo identifies the destination project, service name such as storage.googleapis.com, and method selector such as google.storage.objects.get. Only after the perimeter is updated with that egress_spec.yaml file can data flow from that identity to that specific external method and project, while all other external restricted access remains denied.

Access levels allow defined users or contexts to cross the boundary, and ingress and egress rules allow defined service-to-service calls across perimeters. Security Health Analytics (opens in a new tab) and similar scanners depend on this pattern because the scanning service account must call the APIs it inspects. Each required API must be explicitly permitted by ingress or egress policy, so the regulated perimeter stays closed except for the identities, resources, and methods the exception names. Required APIs for this scanning pattern include BigQuery, Cloud Key Management Service, Cloud Logging, Cloud Monitoring, Cloud Resource Manager, Cloud Storage, Compute Engine, Identity and Access Management, Kubernetes Engine, and Binary Authorization APIs.

Data governance and storage security requirements translate regulatory baselines into technical controls for storage and database services in Google Cloud. The controls prove where regulated data lives, who holds the encryption keys, how long data is preserved, and who is responsible for each decision. Together they satisfy data sovereignty, lifecycle compliance, and audit requirements for regimes such as PCI DSS, GDPR, HIPAA, and financial-services regulations.

2.1Customer-Managed Encryption and Hardware-Backed Key Control

Customer-managed encryption and hardware-backed key control give the customer ownership of the keys that protect data at rest. Customer-Managed Encryption Keys (CMEK) (opens in a new tab) are encryption keys that the customer creates, owns, and manages in Cloud Key Management Service (Cloud KMS) to protect data at rest. Google Cloud encrypts stored customer data by default with Advanced Encryption Standard (AES) using 256-bit keys and protects data in transit with Transport Layer Security (TLS) without manual setup. CMEK replaces Google-managed key control with customer control, so data flows from the storage or database service to Cloud KMS for wrap and unwrap operations and access depends on the customer key remaining enabled.

Cloud HSM is the hardware-backed protection level in Cloud KMS for storing CMEKs in a Hardware Security Module. Strict governance requires imported keys stored with protection level set to HSM, which keeps key material in tamper-resistant hardware and supports rotation, disablement, and revocation lifecycles. Revoking or destroying the CMEK makes the protected data unreadable, so key lifecycle control becomes a direct enforcement point for sovereignty and destruction mandates. CMEK coverage spans Cloud Storage buckets, BigQuery datasets and tables, Spanner data and backups, Cloud SQL data and backups, Bigtable data and backups, AlloyDB, Pub/Sub topics, Cloud Logging buckets, Compute Engine persistent disks and snapshots, and many Vertex AI and analytics resources.

Governance over CMEK depends on Organization Policy. The constraint constraints/gcp.restrictCmekCryptoKeyProjects restricts which projects, folders, or organizations in the allowedValues list may host CMEK keys, so workloads can only depend on approved key projects. Additional detective controls flag CMEK_NOT_USED when a resource lacks CMEK and CMEK_KEY_NOT_IMPORTED_OR_NOT_HSM when keys are not imported or not HSM-backed. For services such as Google SecOps, CMEK can only be enabled on a new instance and requires granting the service access to the Cloud KMS key during creation.

2.2Data Sovereignty Through Resource Location Constraints

Data sovereignty through Resource Location Constraints defines where Google Cloud resources can be created and where data can be stored and processed. Resource Location Constraints are Organization Policy controls that apply to the organization, folder, or project hierarchy, and Google Cloud enforces the allowed regions before any storage bucket, database, or logging bucket is provisioned. Because services differ in regionality, governance must account for regional resources, multi-regional resources, and global constructs that replicate data across boundaries.

Sovereignty design starts by choosing Google Cloud regions that meet data residency obligations and then blocking drift outside them. Related controls disable Spanner multi-region instances, disable creation of global load balancers and global Cloud Armor policies, define allowed locations for Cloud Logging buckets, and restrict technical support service locations. Assured Workloads (opens in a new tab) extends the boundary with an EU data boundary, routing of support to EU persons in EU locations, visibility into administrative access, and custom encryption and key management options. The boundary separates compliant folders and projects that may hold regulated data from general commercial infrastructure that must not receive it.

2.3Immutable Retention and Lifecycle Compliance

Immutable retention and lifecycle compliance preserve regulated records for a defined period and prove that preservation to auditors. Immutable retention policies are Cloud Storage controls that preserve objects for a defined retention period to meet audit and financial-regulation mandates. A retention period defines how long each object in a bucket must be retained, while a locked retention policy makes that retention immutable so objects cannot be deleted or overwritten until the period expires. The lock transitions the bucket from a reversible configuration state to an irreversible locked state, which auditors rely on as proof that records were preserved.

Lifecycle compliance combines retention with versioning and class transitions. Object versioning on buckets preserves prior versions to prevent data loss and support rapid recovery, and storage-class lifecycle actions move data through cost tiers without breaking retention. CIS and IL5 control sets require defining retention periods for Cloud Storage buckets and locking those policies for regulated workloads. Choose a locked retention policy when regulations require write-once preservation; choose versioning plus regional deployment when the goal is availability and recovery rather than legal immutability.

2.4Governance Boundaries and Shared Responsibility

Governance boundaries and shared responsibility divide data governance between Google and the customer across the resource hierarchy. Google is responsible for default encryption, infrastructure controls, enforcement of the Identity and Access Management (IAM) policies the customer sets, and enforcement of selected Assured Workloads controls for storage location and personnel access. The customer is responsible for classifying which data has heightened compliance needs, placing that data inside appropriate Assured Workloads folders or projects and keeping it there, configuring IAM and the organization-folder-project hierarchy, and validating controls with internal testing and external audit.

A critical governance boundary excludes regulated data from metadata fields that sit outside the technical control boundary. Regulated customers must not place sensitive data such as account information, health information, personal identifiers, cardholder data, or ID numbers in:

• Resource names and IDs, including project or folder names and IDs
• Description fields, labels, and log-based metrics
• URIs, file paths, VM sizes, and service configurations
• Firewall rules, security scanning configurations, and customer IAM policies
• Timestamps, user IDs, and similar operational fields

Compliance controls for compute and workload isolation are the technical baselines that prove virtual machines and containers run only trusted code in isolated execution environments. In Google Cloud, Compute Engine (opens in a new tab) and Google Kubernetes Engine (GKE) divide this work between hardened images, attested boot, encrypted memory, and immutable workloads, with Google securing the underlying platform and the customer securing code, images, and access policy. Together these controls satisfy regulatory mandates for integrity, separation, and verifiable patching.

3.1Risk-Aligned Baselines for Compute

Risk-aligned baselines for compute map regulatory requirements to technical controls through a cloud-specific risk assessment. Frameworks such as the Cloud Security Alliance Cloud Controls Matrix (CCM) provide a catalog of risks and mitigations, while threat modeling such as the OWASP method identifies gaps in application and infrastructure design. The assessment must account for shared responsibility (opens in a new tab), because hardware and physical risks sit with Google while workload risks remain with the customer, and the boundary shifts between Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). The resulting mitigation plan combines technical controls, operational processes, contractual protections, and third-party attestations, with Center for Internet Security (CIS) benchmarks used to harden operating system and application images.

3.2Hardened Images and Shielded VMs in Compute Engine

Hardened images and Shielded VMs in Compute Engine ensure that every virtual machine (VM) starts from a patched and minimal baseline. If a team uses custom images, the team must patch those images itself, while Google-provided curated operating system (OS) images are patched regularly by Google. For containers on VMs, Google-curated Container-Optimized OS images provide a minimal, regularly updated host OS that reduces attack surface compared to a general-purpose OS.

For sensitive workloads, Shielded VM adds attested boot integrity on top of a hardened image. A Shielded VM prevents malicious code from loading during the boot cycle, provides boot security and integrity monitoring, and uses the Virtual Trusted Platform Module (vTPM) as a hardware root of trust for measurements. This means the trust boundary for boot moves from mutable startup code to verified firmware and kernel measurements, so a compromised driver or rootkit that alters the boot sequence can be detected before the workload handles regulated data.

3.3Confidential Computing for Data in Use

Confidential Computing for data in use protects data held in system memory during processing. Google Cloud encrypts customer data at rest by default and encrypts and authenticates data in transit at one or more network layers, including VM-to-VM traffic within a Virtual Private Cloud (VPC) network and between peered VPC networks. Data in memory is not encrypted by default, so organizations that handle confidential data need a trusted execution environment that encrypts memory and protects the confidentiality and integrity of the application from the host, hypervisor, and Google operators.

The Confidential Computing portfolio reduces the trust boundary so fewer resources outside the encrypted enclave can access confidential data. Confidential VM protects Compute Engine workloads that use VMs, Confidential GKE Nodes protect container workloads that use GKE nodes, and Confidential Space protects joint data analysis and machine learning across trust boundaries. Choose a Confidential VM when isolation is needed for a single VM, choose Confidential GKE Nodes when isolation is needed for container nodes and pods, and choose Confidential Space when multiple parties must collaborate without exposing plaintext to each other or the platform.

3.4Hardened GKE Containers and Node Operations

Hardened GKE containers and node operations enforce workload integrity by making containers stateless and immutable. Immutability means operators do not modify a running container or access it interactively; if the container must change, the team builds a new image and redeploys that image, with shell or SSH access to containers allowed only for specific debugging scenarios. To further reduce attack surface, teams can use distroless images that contain only the application and its runtime dependencies, which is ideal for security-sensitive microservices where minimizing size and included packages is paramount.

Node and control-plane operations depend on a clear split of patching duties. Google hardens and patches the node OS, such as Container-Optimized OS or Ubuntu, hardens kubelet configuration following CIS benchmarks, and manages Shielded GKE Nodes with vTPM-backed trusted bootstrap and auto-rotation of kubelet Transport Layer Security (TLS) certificates. Google also hardens and patches the control plane, including the API server, scheduler, controller manager, cluster certificate authority, etcd, and the Identity and Access Management (IAM) authenticator and authorizer, with all control-plane components running on Google-operated, single-tenant Compute Engine instances. The customer remains responsible for application code, build files, container images, data, role-based access control (RBAC) and IAM policy, rotation of cluster credentials, keeping Standard node pools enrolled in automatic upgrades, manually upgrading when maintenance postponements or patch timelines require it, and keeping logging and monitoring enabled so support and incident response have telemetry.

3.5Identity Controls and Preventive Guardrails for Isolation

Identity controls and preventive guardrails for isolation limit blast radius by tying access to identity and blocking noncompliant compute before it is created. OS Login (opens in a new tab) replaces distributed Secure Shell (SSH) keys with IAM permissions as the source of truth for Linux VM access, ties administrator access to employee lifecycle so access is revoked when roles change or accounts leave, and supports two-factor authentication against account takeover. For GKE, the GKE metadata server supports Workload Identity so workloads authenticate to Google APIs without long-lived keys, while dedicated service accounts with least privilege replace broad default service accounts for Compute Engine VMs.

Organization policies apply global constraints that prevent noncompliant compute from being created at the organization, folder, or project level. Representative guardrails supported by the documentation are:

• Disable external IP address allocation to VMs to remove direct internet ingress.
• Restrict resource creation to specific geographical locations to enforce residency.
• Disable creation of service accounts or service account keys to prevent privilege sprawl.

These guardrails work with network isolation, where VMs without external addresses use Private Google Access or Private Service Connect for Google APIs and use Cloud Network Address Translation (NAT) or Secure Web Proxy for controlled outbound access, while VPC Service Controls and strict egress firewall rules establish perimeters against data exfiltration. Zero trust controls (opens in a new tab) extend this model by continuously verifying identity and context before allowing workload access.

Key Facts

• VPC Service Controls denies API-level data movement across its perimeter even when Identity and Access Management permissions would allow it, and new perimeters for production should run in dry run mode before moving to enforced mode.
• Traffic flows from workloads to Google APIs through a Private Service Connect endpoint such as 10.0.1.1, while a priority-1000 firewall rule allows TCP 443 to that endpoint and a priority-65534 rule denies all other egress to 0.0.0.0/0.
• Customer-Managed Encryption Keys (CMEK) in Cloud Key Management Service with protection level HSM keep key material in tamper-resistant hardware, and revoking or destroying the key makes the protected data unreadable.
• A locked Cloud Storage retention policy transitions a bucket to an irreversible locked state where objects cannot be deleted or overwritten until the retention period expires.
• Shielded VM uses a Virtual Trusted Platform Module (vTPM) to verify boot integrity, while Confidential VM and Confidential GKE Nodes encrypt memory to protect data in use.