Security guide

Secure GCP Architecture: Reference Design and Checklist

A secure GCP architecture puts the guardrails in before the workloads. Google's enterprise foundations blueprint describes the shape: one organization with folders by environment, identity from a central provider with roles granted to groups, a centrally managed network with public internet traffic blocked by default, audit logs aggregated to one project, and keys and secrets in dedicated projects.

This guide draws that design, explains each area in plain words, maps it to the Google Cloud Architecture Framework security pillar and ends with a decision checklist. Every claim comes from Google Cloud documentation read on 4 November 2026.

Updated 4 November 2026 (last reviewed)

TL;DR

The short version

5 points

Google's enterprise foundations blueprint (formerly security foundations) is a baseline of resources and controls: policy controls, architecture controls and detective controls, with Terraform code in the terraform-example-foundation repository.
Hierarchy: one organization, folders by environment, projects with governance labels, organization policies inherited.
Identity: users synced from your identity provider, roles to groups by job function, no exported service account keys.
Network: Shared VPC managed centrally, private paths to Google services, public traffic blocked by default, VPC Service Controls around sensitive data.
Logging: aggregated sinks to a central project, Security Command Center for detection. Data protection: public access prevention, CMEK where needed, keys and secrets in centralized projects.

The reference architecture

Read the figure from the top: identity and policy attach to the organization, projects sit in folders, shared services are in one folder, and the production projects that hold sensitive data sit inside a perimeter.

Figure 1. Reference architecture. The blueprint describes a single organization with folders by environment, Shared VPC, aggregated log sinks to a central project, and centralized projects for Cloud KMS and Secret Manager; the names and layout here are our illustration.

Design areas, the blueprint and the framework

The blueprint is the concrete design; the Architecture Framework security pillar supplies the principles. Google lists seven: security by design, zero trust, shift-left security, preemptive cyber defense, using AI securely and responsibly, using AI for security, and meeting regulatory, compliance and privacy needs. The table maps design areas to them. The last column of principle notes is our mapping, not a Google table.

Area	What to do	Principle (our mapping)	Source
Resource hierarchy	One organization, folders by environment, projects with governance labels; organization policies inherited down.	Architecture control and policy control in the blueprint.	Enterprise foundations blueprint, Org policy constraints
Identity	Cloud Identity synced from your identity provider; IAM roles to groups by job function; view-only humans; changes through a pipeline.	Zero trust: continuous verification and least privilege.	Enterprise foundations blueprint, Architecture Framework security pillar, IAM role recommender
Workload identity	No exported service account keys; Workload Identity Federation for external and Kubernetes workloads, with attribute conditions.	Security by design: remove the credential that leaks.	Service account keys, Workload Identity Federation, GKE Workload Identity, Architecture Framework security pillar
Network	Shared VPC managed centrally and separated by environment; private paths to Google services; public traffic blocked by default; VPC Service Controls around sensitive data.	Architecture control; zero trust.	Enterprise foundations blueprint, Shared VPC, VPC Service Controls
Logging and detection	Aggregated sinks to a central project; Data Access logs for sensitive services; Security Command Center and a SOC integration.	Detective controls; preemptive defence.	Enterprise foundations blueprint, Aggregated sinks, Cloud Audit Logs, Security Command Center, Event Threat Detection
Data protection	Storage public access prevention and uniform bucket-level access; CMEK where required; Secret Manager and Cloud KMS in centralized projects.	Meet regulatory, compliance and privacy needs.	Public access prevention, Uniform bucket-level access, CMEK, Enterprise foundations blueprint
Delivery	Terraform in version control, review and approval, Cloud Build with policy-as-code checks.	Shift-left security.	Enterprise foundations blueprint, Architecture Framework security pillar

Resource hierarchy and organization policy

The blueprint uses a single organization with folders that group projects by environment, and projects carry governance labels such as cost attribution (Enterprise foundations blueprint). Put controls as high as you can, because lower levels inherit them. Organization policy constraints can be set at the organization, folder or project level (Org policy constraints). Constraints worth setting early include constraints/compute.skipDefaultNetworkCreation, constraints/iam.allowedPolicyMemberDomains and constraints/gcp.resourceLocations.

Identity and workload identity

For people, the blueprint syncs users and groups from an existing identity provider, grants IAM allow policies to groups by job function, gives users view-only access and sends changes through a CI/CD pipeline that uses privileged service accounts (Enterprise foundations blueprint). Trim excess with the IAM role recommender: it compares granted permissions with those used over up to 90 days and never applies changes automatically.

For machines, avoid keys. Google says a service account key works like a password and service accounts have no 2-step verification, and recommends the constraints constraints/iam.managed.disableServiceAccountKeyCreation and constraints/iam.managed.disableServiceAccountKeyUpload (Service account keys; Org policy constraints). Use Workload Identity Federation for external workloads, with an attribute condition on each provider, and GKE Workload Identity for pods. See the response drill in the GCP Incident Triage Lab.

Network and the data perimeter

The blueprint uses Shared VPC for centrally managed network resources separated by environment, private paths between on-premises, VPC and Google services, and blocks inbound and outbound public internet traffic by default (Enterprise foundations blueprint). Shared VPC keeps subnets, routes and firewalls under host-project administration so network and security duties can be separated (Shared VPC).

VPC Service Controls adds a perimeter around Google-managed services such as Cloud Storage and BigQuery. It limits copies of data to unauthorized resources and helps against stolen OAuth or service account credentials and IAM misconfiguration. Use dry run mode to see what a perimeter would block before you enforce it.

Logging and detection

The blueprint uses aggregated log sinks to send security and audit logs to a centralized project for retention, analysis and export (Enterprise foundations blueprint). An aggregated sink routes entries from all resources in a folder or organization to one destination (Aggregated sinks). Remember that Admin Activity and System Event audit logs are always written, but Data Access logs are off by default for every service except BigQuery (Cloud Audit Logs). For detection, Security Command Center covers misconfigurations and threats and exports findings to BigQuery and Pub/Sub, and Event Threat Detection reads audit logs in near real time.

Data protection

The blueprint keeps Secret Manager and Cloud KMS in centralized projects, each managed and audited by a dedicated team (Enterprise foundations blueprint). For Cloud Storage, public access prevention blocks access grants to public principals and uniform bucket-level access makes IAM the only access control. CMEK gives you control of the key but, if the key is disabled or destroyed, the data cannot be accessed, so plan for it. Related constraints: constraints/storage.publicAccessPrevention, constraints/storage.uniformBucketLevelAccess, constraints/gcp.restrictNonCmekServices.

Decision checklist

Answer each with yes, partly or no. Every “no” is a design decision to make. For a scored version with per-domain gaps and export, use the GCP Security Checklist.

Do all projects sit under one organization, in folders by environment, with organization policies set above the projects?
Are users and groups synced from a central identity provider, with roles granted to groups by job function?
Is service account key creation and upload disabled by policy, with every exception documented?
Do external and Kubernetes workloads use Workload Identity Federation, each provider with an attribute condition?
Is domain restricted sharing set, and have outside accounts been reviewed?
Are basic roles gone from production, and are IAM role recommendations reviewed?
Is the network centrally managed (Shared VPC or equivalent), with the default network skipped and external VM IPs denied?
Do sensitive-data projects sit inside a VPC Service Controls perimeter that was tested in dry run first?
Are audit logs routed by organization-level aggregated sinks to a central project, with Data Access logs on for sensitive services?
Is Security Command Center activated at the organization level, with findings routed to owners and a SOC?
Is Cloud Storage public access prevention enforced and uniform bucket-level access required?
Where CMEK is required, is there a plan for key disablement, and are keys rotated and not public?
Are infrastructure changes deployed from version control through a pipeline with policy checks?
Have you rehearsed the response to a leaked key and a compromised workload identity?

What this guide does not claim

The folder and project names in the diagram are illustrative. The blueprint page we read does not name specific folders or projects.
The Google pages we read do not state a last-updated date in the text, so none is claimed. Last reviewed 4 November 2026.
This is not the CIS benchmark (CIS GCP Benchmark shows version 5.0.0 as the latest on our access date) and not a compliance opinion.
Security Command Center's Enterprise tier is described as deprecated, with a shutdown date of 21 May 2027 (Security Command Center); check tiers before you plan.

Frequently asked questions

What is a secure GCP architecture?

It is a Google Cloud setup where guardrails are built in before workloads arrive: one organization with folders by environment, identity from a central provider with roles granted to groups, a centrally managed network with no public internet traffic by default, audit logs aggregated to a central project, and encryption keys and secrets in dedicated projects. Google's enterprise foundations blueprint describes this baseline.

What is the Google Cloud enterprise foundations blueprint?

It is Google's baseline of resources, configurations and capabilities for adopting Google Cloud with consistent governance, security controls and visibility. It has a terraform-example-foundation GitHub repository of deployable Terraform assets and a guide describing the architecture. Google previously called it the security foundations blueprint.

How does the Architecture Framework security pillar relate?

The Architecture Framework's Security, Privacy and Compliance pillar sets principles such as security by design, zero trust, shift-left security and meeting regulatory needs. The foundations blueprint is a concrete implementation of many of those principles; this guide maps each design area to them.

Do I need VPC Service Controls?

Not for every workload. Google describes it as a boundary around services such as Cloud Storage and BigQuery that reduces the risk of data leaving, including through stolen credentials or IAM misconfiguration. It is worth it for sensitive data, and Google provides a dry run mode so you can test a perimeter before enforcing it.

Should I use service account keys?

Avoid them. Google says a key works like a password with no 2-step verification, recommends organization policy constraints that disable key creation and upload by default, and recommends Workload Identity Federation for external workloads. If a key leaks, delete it quickly.

Is this the same as CIS compliance?

No. The CIS Google Cloud Platform Foundation Benchmark is a separate, versioned checklist (version 5.0.0 on the CIS page at our access date). The architecture here is design guidance. Use the GCP Security Checklist for a quick gap review and the benchmark for audit evidence.