Google Cloud Security Guide

Most Google Cloud incidents trace back to identity and configuration, not to a flaw in the platform: a downloaded service account key, a basic role granted to a whole team, a bucket opened to the internet or audit logs nobody turned on. Google Cloud gives you strong controls, but they work only when the estate is built around its resource hierarchy, with guardrails set at the organisation and inherited downwards. This guide covers the hierarchy, Organization Policy constraints, IAM (roles, deny policies, Principal Access Boundary and the IAM recommender), service accounts and workload identity federation, VPC Service Controls, Cloud Audit Logs, Security Command Center, Cloud KMS and CMEK, Shielded and Confidential VMs, GKE hardening, and the CIS benchmark and enterprise foundations blueprint. It is written for cloud security engineers, platform teams and architects who build or inherit a Google Cloud organisation.

Key takeaways

• The hierarchy is your control plane. Organisation, folders and projects decide where allow policies, deny policies and organisation policies apply, and everything set high up is inherited below.
• Keys are the main NHI risk. Block service account key creation and upload, move workloads to attached service accounts and workload identity federation, and treat any remaining key as a tracked exception.
• Basic roles do not belong in production. Owner, Editor and Viewer carry thousands of permissions; use predefined or custom roles, prune with the IAM recommender and add deny policies for the actions nobody should take.
• Data Access logs are mostly off. Admin Activity logs are always written, but Data Access audit logs are disabled by default for every service except BigQuery, so turn them on where sensitive data lives.
• Check your Security Command Center tier. Standard is free, Premium adds threat detection and attack paths, and the Enterprise tier is deprecated and shuts down on 21 May 2027.

Design the resource hierarchy first

Google Cloud resources sit in a four-level hierarchy: the organisation resource at the root, optional folders, projects, and the service resources inside projects (VMs, buckets, datasets). Google's documentation states that "Allow, deny, and organization policies are inherited through the hierarchy." The effective policy on a resource is what is set on it plus everything inherited, so the hierarchy encodes security intent, not just billing.

• Organisation resource: it requires a Google Workspace or Cloud Identity account. Projects outside it escape central policy, so bring them in early.
• Folders: group projects by environment and shared function (security, logging, networking), with stricter policies on production.
• Projects: the unit of isolation for APIs and most IAM grants; one workload per project per environment keeps blast radius small.
• Security projects: keep log sinks, Cloud KMS key rings and break-glass identities in projects workload teams cannot administer.

Google's enterprise foundations blueprint (formerly the security foundations blueprint) is the reference landing zone: a folder hierarchy by environment, Shared VPC for networking, aggregated log sinks, Security Command Center for detective controls and organisation policy constraints for preventive ones, published as Terraform in the terraform-example-foundation repository. Its networking default is blunt and worth copying: "No outbound traffic to or inbound traffic from the public internet is permitted by default." Every foundation change goes through a Cloud Build pipeline with policy-as-code checks.

Organization Policy constraints: the preventive guardrails

IAM decides who can act; the Organization Policy Service decides which configurations are allowed at all, whoever asks. Policies are inherited downwards unless a descendant may override them. Organisations created on or after 3 May 2024 get a security baseline by default; older ones must set it themselves.

Roll out new constraints in dry-run mode first: Google's documentation says that in dry run "violations of the policy are audit-logged, but the violating actions aren't denied." Review the violations, fix or exempt the projects concerned, then enforce. Where a constraint has a managed variant, prefer it, and check what your organisation already enforces before writing Terraform that fights the defaults.

IAM: roles, deny policies and access boundaries

Choose the right role type

Google's own guidance is direct: "In production environments, do not grant basic roles unless there is no alternative." Grant roles to groups rather than individuals, prefer project-level grants over folder or organisation grants, and add IAM conditions (time-bound or tag-based) for elevated access.

Prune with the IAM recommender

The IAM recommender compares granted permissions with use over up to 90 days and suggests REMOVE_ROLE or REPLACE_ROLE at project, folder and organisation level. It never applies changes itself, skips conditional bindings and ignores ACLs and Kubernetes RBAC. Treat it as a review queue: non-production first, then production with an owner's sign-off.

Deny policies and Principal Access Boundary

• Deny policies: "IAM always checks relevant deny policies before checking relevant allow policies." Attach them to the organisation, a folder or a project; they are inherited and use permission names such as iam.googleapis.com/serviceAccountKeys.create. Use them to stop anyone except a named break-glass group from deleting log sinks, changing organisation policies or creating keys, with exceptionPrincipals for that group.
• Principal Access Boundary (PAB) policies: they work from the other direction, limiting which resources a set of principals is eligible to access at all, whatever roles they hold. They bind to principal sets such as workforce or workload identity pools, a Workspace domain or an organisation's principals. They "can only block or not block access", fail closed and cover only supported permissions, so test before enforcing. Keeping your principals inside your own organisation blocks copying data to an attacker's project.

See the Cloud PAM and CIEM Guide.

Service accounts, keys and workload identity

Service accounts are Google Cloud's workload identities and the platform's most important non-human identities. Google's key guidance says "authenticating by using a leaked service account key is likely to succeed" and that keys should be "an exception rather than the norm". By default a user-managed key never expires.

• Attached service accounts: workloads on Compute Engine, Cloud Run, Cloud Functions and GKE obtain short-lived tokens from the metadata server, with no key file. Create a dedicated service account per workload; do not use the Compute Engine default service account, which historically received Editor.
• Workload identity federation: workloads on AWS, Azure, GitHub, GitLab, on-premises Active Directory or any OIDC or SAML 2.0 identity provider exchange their own credential through the Security Token Service for a short-lived federated token. Google says it "eliminates the maintenance and security burden associated with service account keys." Grant roles directly to the federated principal where the API supports it, and always set attribute conditions (for example, a specific repository and branch) because a pool that trusts every identity from a provider "can incur risk."
• Impersonation: people who must act as a service account should impersonate it (Service Account Token Creator on that one account) rather than hold a key.
• Remaining keys: set a key expiry for new keys, enforce the Service Account Key Exposure Response constraint with DISABLE_KEY so leaked keys Google detects are disabled automatically, and remember that Google "doesn't guarantee that it will detect leaked keys."
• API keys: they are a separate credential type. Restrict each key to named APIs and to application or IP restrictions. The Google API Keys Exposure 2026 shows how a key published as harmless became a secret once a new API was enabled on its project.

Watch iam.serviceAccounts.actAs and iam.serviceAccounts.getAccessToken: whoever can act as a privileged service account holds its permissions, and the recommender's lateral movement insights flag these paths. See the Cloud Workload Identity Guide and the Service Account Security Guide.

Network and data perimeter

• VPC firewall rules and hierarchical firewall policies: set organisation- or folder-level policies for rules nobody may override (for example, deny SSH and RDP from 0.0.0.0/0), and use service-account-based targets rather than network tags where possible, because tags can be changed by anyone who can edit the instance. See the Firewall Management Guide.
• Private Google Access and private endpoints: let VMs without external IPs reach Google APIs, and combine with restricted.googleapis.com (199.36.153.4/30, not announced to the internet) when using VPC Service Controls.
• VPC Service Controls: service perimeters around projects stop data being read from or copied to resources outside the perimeter through Google APIs, even by a principal with valid IAM rights. Access Context Manager access levels admit callers by IP, device or location; ingress and egress rules (preferred over bridges) allow named flows. Know the limits: not every service is supported, it "is not designed to enforce comprehensive controls on metadata movement", and it "does not block access to any third-party API or services on the internet", so egress filtering is still needed.
• Edge services: Google Cloud Armor applies WAF and DDoS policies at external load balancers; Identity-Aware Proxy fronts internal apps and SSH with identity checks.

Run every perimeter in dry-run mode first: violations are logged without blocking, revealing the jobs that would break.

Logging and detection

Cloud Audit Logs

Create an organisation-level aggregated sink sending all child projects' logs to a locked bucket or BigQuery dataset in a logging project. Protect the sink with a deny policy, because deleting or redirecting it (ATT&CK T1685 Disable or Modify Tools, under the v20 Defense Impairment tactic) blinds you. See the Log Management and Retention Guide.

Security Command Center tiers

If you rely on Enterprise for AWS and Azure coverage, plan the replacement now. Activate at organisation level where you can: attack path simulations, among other features, need it. See the CNAPP Guide.

Data protection, compute and GKE

• Default encryption and CMEK: all data at rest is encrypted with Google-owned keys you cannot see or audit. Customer-managed encryption keys (CMEK) in Cloud KMS add control over rotation, location, access and destruction, including crypto-shredding. Enforce them with the gcp.restrictNonCmekServices and gcp.restrictCmekCryptoKeyProjects constraints, and use Cloud KMS Autokey to provision keys on demand. The risk cuts both ways: "if you disable or destroy the CMEK, that data can't be accessed", and some services lose data permanently if a key stays unavailable too long. See the Cryptographic Key Management Guide.
• Cloud Storage: uniform bucket-level access, public access prevention and domain restricted sharing together stop accidental public buckets. Firebase projects are Google Cloud projects too, and the Firebase misconfigurations of 2024 show what open data rules expose.
• Shielded VM: Secure Boot verifies boot component signatures, the vTPM enables Measured Boot, and integrity monitoring raises earlyBootReportEvent and lateBootReportEvent results in Cloud Logging and Security Command Center. vTPM and integrity monitoring are on by default; Secure Boot must be enabled, and compute.requireShieldedVm enforces Shielded VMs across the organisation.
• Confidential VM: encrypts memory in use with AMD SEV, SEV-SNP or Intel TDX, for workloads where the threat model includes the host. See the Confidential Computing Guide.
• GKE: Google calls Workload Identity Federation for GKE "the recommended way to authenticate to Google Cloud APIs." Use a least-privilege node service account, private nodes, the DNS-based control plane endpoint (or authorised networks), Shielded GKE Nodes, Container-Optimized OS and automatic upgrades, and never enable legacy ABAC. Autopilot starts stricter than Standard. Binary Authorization can require signed images at deploy time. See the Kubernetes NHI Security Guide.

Implementation roadmap

1. Inventory (weeks 1 to 2): confirm one organisation resource, export Cloud Asset Inventory, and list user-managed keys and basic role grants.
2. Baseline guardrails (weeks 2 to 4): apply the secure-by-default constraints in dry run on the organisation, review violations, exempt named projects with an expiry date, then enforce. Roll back by removing enforcement on the affected folder, not by disabling the constraint organisation-wide.
3. Logging (weeks 3 to 5): create the organisation aggregated sink, enable Data Access logs for sensitive services in production, and protect sinks with a deny policy tested first on a non-production folder.
4. Identity clean-up (weeks 4 to 10): replace keys with attached service accounts or federation pipeline by pipeline, and remove basic roles using recommender output.
5. Detection (weeks 6 to 8): activate Security Command Center at organisation level and route high and critical findings to the SOC.
6. Perimeters (weeks 8 to 16): deploy VPC Service Controls around data projects in dry run for at least two business cycles (including month-end jobs), then enforce one perimeter at a time.
7. Codify: keep all of this in Terraform with policy-as-code checks, so a bad change is reverted with a commit.

Decision guidance

• Small estates: Security Command Center Standard, the secure-by-default constraints, predefined roles, federation for CI and an aggregated sink cover most risk; VPC Service Controls may cost more in friction than it returns.
• Large or regulated estates: the blueprint hierarchy, Premium at organisation level, perimeters around regulated data, CMEK in separate key projects, deny and PAB policies, and a platform team owning organisation-level IAM.
• Predefined or custom role: start predefined; build custom roles only where the recommender shows a predefined role is consistently over-broad, since you must maintain them.
• Google default encryption or CMEK: CMEK adds operational risk (key loss is data loss). Choose it where regulation, contractual control or crypto-shredding requires it, not by default everywhere.

Detection and measurement

Alert on organisation- or folder-level SetIamPolicy, any google.iam.admin.v1.CreateServiceAccountKey, sink deletion, organisation policy changes and new workload identity pool providers. In ATT&CK v20 terms these cover Valid Accounts: Cloud Accounts (T1078.004), Additional Cloud Roles (T1098.003), Data from Cloud Storage (T1530), Transfer Data to Cloud Account (T1537) and Resource Hijacking (T1496), which is what stolen keys are often used for, as the LLMjacking cases show.

Common failure patterns

• Keys in CI and laptops: a JSON key created "temporarily" for a pipeline, copied around and never rotated. Federation removes the file. See the Secrets Management Guide.
• Federation without conditions: a GitHub OIDC provider whose pool accepts any repository, so any GitHub user's workflow can obtain a token.
• Assuming audit logs exist: discovering after an incident that Data Access logs were never enabled for Cloud Storage, so there is no record of what was read.
• Perimeters switched straight to enforce: VPC Service Controls enforced without dry run breaks pipelines, and the perimeter is then removed and never reinstated.

Framework mapping

Practitioner checklist

• Confirm a single organisation resource and move every project under a folder with an owner.
• Enforce the secure-by-default organisation policies, testing each in dry run first.
• Block service account key creation and upload; track every remaining key with an expiry and owner.
• Move CI and multicloud workloads to workload identity federation with attribute conditions.
• Remove basic roles from production and work the IAM recommender queue monthly.
• Add deny policies protecting log sinks, organisation policies and key creation, with a break-glass exception group.
• Create an organisation aggregated log sink and enable Data Access logs for sensitive services.
• Activate Security Command Center at organisation level and plan the exit from Enterprise before 21 May 2027.
• Put VPC Service Controls perimeters around regulated data after a dry-run period.
• Benchmark against CIS Google Cloud Platform Foundation Benchmark 5.0.0 and keep the foundation in Terraform.

Standards and references

• Google Cloud: Resource hierarchy
• Google Cloud: Secure by default organizations
• Google Cloud: Best practices for managing service account keys
• Google Cloud: Principal Access Boundary policies
• Google Cloud: Overview of VPC Service Controls
• Google Cloud: Security Command Center service tiers
• Google Cloud: Enterprise foundations blueprint
• CIS: Google Cloud Platform Foundation Benchmark

Related NHI Mgmt Group resources: Cloud Workload Identity Guide · Service Account Security Guide · Cloud PAM and CIEM Guide · CNAPP Guide · Kubernetes NHI Security Guide