Google Cloud Security - The Complete Guide

Shared responsibility on GCP

The shared-responsibility model on Google Cloud follows the same shape as AWS and Azure but with Google's own vocabulary. Google is responsible for security of the cloud - the hardware, hypervisor, physical facilities, the global network, the operating systems under managed services, and the security of every API endpoint. You are responsible for security in the cloud - the configuration of IAM, the projects you create, the workloads you deploy, the data you store, and the policies you enforce.

The line moves with the service. For Compute Engine (IaaS), you own the guest OS, the patches, the workload, and the IAM. For Cloud Run or App Engine (PaaS), Google owns the runtime - you own the container image, the IAM, the data. For managed services like BigQuery, Cloud Storage, Pub/Sub, and Spanner, you own the data, the IAM bindings, and the access controls; Google owns everything underneath. Knowing exactly where the line falls for each service is the entire job of a GCP security architect.

Google's security differentiators

Google Cloud's security story is rooted in the same infrastructure that runs Search, Gmail, and YouTube - the world's largest production target for nation-state attackers since the early 2000s. The defensive primitives that protect those services are exposed to GCP customers, and several of them have no clean equivalent at AWS or Azure.

GCP Architecture Framework - Security pillar

Google publishes the Google Cloud Architecture Framework as its opinion on how customers should design GCP workloads. The Security pillar is the practitioner's reference; it organizes the work into seven principles:

• Implement security by design. Threat-model before deploying. Use the org / folder / project hierarchy as the unit of blast-radius isolation. Apply Organization Policy constraints centrally.
• Implement zero trust. Authenticate and authorize every request. Use Identity-Aware Proxy for application access. Use Workload Identity Federation for non-human callers. Never grant project-level Editor.
• Implement shift-left security. Scan code, IaC, and images in CI. Require Binary Authorization for production deploys. Reject non-conformant Terraform plans before apply.
• Implement preemptive cyber defense. Subscribe to threat intel (Mandiant, OSINT). Run red-team exercises. Map detection coverage to MITRE ATT&CK for GCP.
• Use AI securely and responsibly. Apply AI/ML security controls to Vertex AI workloads - model versioning, dataset access logging, prompt-injection guardrails, output classification.
• Use AI for security. Use SCC's AI-driven attack-path analysis and Gemini-in-Security copilots to triage faster. The orgs using AI assistance are dramatically faster at IR.
• Meet regulatory, compliance, and privacy needs. Pick the right Assured Workloads regime up front. Run Compliance Reports Manager continuously. Map controls to your framework (see Compliance Frameworks).

Core GCP security services

Opinionated 2-3 sentences on each. Where a service has a clear analog elsewhere, the comparison points you to the cross-cloud page.

Detection & monitoring

• Security Command Center (SCC). Google's central security platform - three tiers: Standard (free, Security Health Analytics misconfig scanning), Premium (adds Event Threat Detection, Container Threat Detection, Web Security Scanner, attack-path analysis), and Enterprise (Premium + the full SecOps/Chronicle SIEM/SOAR stack with Mandiant threat intel). SCC Enterprise is the rebranded landing zone for Google's post-Mandiant SecOps story; if you want one Google product to be your security platform, this is it.
• Cloud Logging. The aggregation point for all GCP logs - application logs, system logs, audit logs, and customer logs. Pipe through log sinks to BigQuery (for analytics), Cloud Storage (for cold archive), Pub/Sub (for real-time pipelines), or external SIEMs. The most-overlooked footgun: Data Access logs are off by default for most services, so without explicit configuration you have no record of who read what data.
• Cloud Audit Logs. Four categories: Admin Activity (always on, free, immutable - every configuration change), Data Access (off by default for most services, can be expensive at scale, but the only way to see reads), System Event (Google-initiated changes - patches, hardware events), and Policy Denied (denied requests, including VPC SC violations - high signal for misconfigurations and attacks). Configure all four to a dedicated security project log sink early.
• Event Threat Detection (ETD). SCC Premium/Enterprise module that scans your audit log stream for known-malicious patterns - leaked SA keys posted to GitHub, IAM anomalous grants, brute-force SSH, crypto-mining indicators. Detections are Mandiant-curated; the signal-to-noise is meaningfully better than DIY rules in most cases.
• Container Threat Detection (CTD). Runtime detection for GKE - added binaries in running containers, reverse shells, suspicious library loads, cryptominer signatures. Requires kernel-level instrumentation; runs on GKE node images that include the agent.
• Web Security Scanner. Crawls App Engine, Compute Engine, and GKE-hosted web apps for the OWASP top categories - XSS, mixed content, insecure libraries, outdated frameworks. Not a replacement for a real DAST, but a solid free starting point for surfacing the obvious.
• Chronicle SecOps. Google's cloud-native SIEM/SOAR, built on the same infrastructure that powers Search. Flat-fee ingest pricing (no per-GB scaling pain), 12-month default hot retention, YARA-L rule language, native integration with Mandiant threat intel. Now sold inside SCC Enterprise; can also be bought standalone.

Identity & access

• Cloud Identity. Google's free standalone identity platform - users, groups, SSO, MFA, device management - separate from Google Workspace. If you don't use Workspace, this is what gives you a Google-native identity store for GCP. Federate to your existing IdP (Okta, Entra ID) via SAML.
• Identity Platform. Customer-facing identity (CIAM) for your applications - built on the Firebase Authentication codebase but enterprise-tier. Use it for end-user identity, not workforce identity.
• Cloud IAM. The authorization layer for every GCP resource. Three principal types (users, groups, service accounts), three role types (basic - Owner/Editor/Viewer, predefined, custom), and bindings at organization / folder / project / resource scope. The hierarchical inheritance is the model's strength and its biggest footgun - a grant at the org level applies to every project unless explicitly denied.
• Workload Identity Federation. The right answer to "how do I avoid hardcoded service account JSON keys?" Lets workloads outside GCP (AWS, Azure, GitHub Actions, Kubernetes, OIDC anything) assume a GCP service account via short-lived tokens. The single most-impactful security upgrade for any GCP customer with CI/CD outside GCP - eliminates the entire SA-key-leak class of incidents.
• Identity-Aware Proxy (IAP). A managed reverse proxy that requires Google identity + IAM authorization before forwarding traffic to a backend. Works for App Engine, Compute Engine, GKE, and on-prem workloads via IAP TCP forwarding. Replaces VPN for most internal-application access; the foundation of BeyondCorp Enterprise.
• BeyondCorp Enterprise. Google's productized zero-trust suite - IAP + Access Context Manager + Endpoint Verification + threat & data protection in the browser. Effectively a ZTNA + secure-browser product line, sold per-user; the GCP-native answer if you'd otherwise be buying Zscaler, Netskope, or Cloudflare Access.
• Access Context Manager (ACM). The policy engine behind IAP and VPC SC. Define access levels from attributes - IP range, geography, device-trust signals, identity - and attach them as conditions on IAM bindings or VPC SC ingress rules.
• Policy Intelligence. The umbrella for IAM Recommender (suggests least-privilege replacements based on actual usage), Policy Analyzer (answers "who can do what on this resource?"), Policy Troubleshooter (explains why a request was denied or allowed), and Policy Simulator (preview the effect of an IAM change before applying it). The combination of Recommender + Analyzer is one of GCP's most underused features.

Data protection

• Cloud KMS. Google-managed key service. Software-protected (default) or HSM-backed (Cloud HSM, FIPS 140-2 Level 3) keyrings. Use Customer-Managed Encryption Keys (CMEK) on every service that supports them; the marginal cost is small, the audit-evidence and control-plane value is large.
• Cloud External Key Manager (EKM). Lets you hold keys in a third-party HSM (Fortanix, Thales, Equinix SmartKey, Virtru, etc.) outside Google's boundary, while still using them transparently with GCS, BigQuery, Compute Engine, and others. The right answer when regulators want literal possession of the keys.
• Secret Manager. Managed secret storage with versioning, IAM-scoped access, automatic rotation triggers (via Cloud Functions), and audit logging. Bind workloads via Workload Identity or service-account IAM; never write secrets into Cloud Build substitutions or Cloud Functions environment variables in plaintext.
• Confidential Computing. Three flavors: Confidential VMs (AMD SEV / SEV-SNP and Intel TDX memory encryption for Compute Engine), Confidential GKE (same protection for GKE nodes), and Confidential Space (attested workloads for multi-party computation - share data with a partner without either side seeing the other's plaintext). Useful for regulated industries and for any workload where memory-bus snooping is in the threat model.
• VPC Service Controls (VPC SC). The data-exfiltration-prevention primitive. See the deep-dive below.
• Sensitive Data Protection (formerly Cloud DLP). Detection, classification, and de-identification of sensitive data in GCS, BigQuery, datastores, and streaming pipelines. 150+ pre-built infoType detectors (PII, credentials, financial data); supports tokenization, masking, format-preserving encryption, and redaction. Pair with VPC SC for a full data-handling story.

Network security

• Cloud Armor. Google's WAF + DDoS protection, attached to global HTTP(S) load balancers. Preconfigured OWASP top-10 rules, custom expression language (CEL) for application-specific rules, Adaptive Protection (ML-driven DDoS), and bot management. Sits at Google's edge - uses the same infrastructure that absorbs the largest DDoS attacks publicly recorded.
• Cloud NGFW Enterprise. Next-gen firewall - TLS inspection, IPS, application-aware filtering - powered by a Palo Alto Networks Threat Prevention partnership. Sold as a managed L7 capability on top of standard VPC firewall rules. The right answer when you need east-west L7 inspection inside GCP without deploying virtual appliances.
• VPC Service Controls. The killer feature - service perimeter for data exfiltration prevention. See the deep-dive.
• Private Service Connect (PSC). Private connectivity to Google APIs, Google-managed services, and third-party services without traversing the public internet - equivalent to AWS PrivateLink. Use PSC endpoints to make Cloud Storage / BigQuery / Pub/Sub reachable only via internal IPs inside your VPC.
• Cloud Intrusion Detection System (Cloud IDS). Network-based IDS using Palo Alto threat signatures. Mirrors VPC traffic to a managed IDS endpoint; emits findings to SCC. East-west network detection without running your own sensors.
• Network Intelligence Center. Connectivity Tests, Network Topology, Performance Dashboard, Firewall Insights, and Network Security Insights - the diagnostics layer for the VPC. The Firewall Insights signal "this rule has been in place for 6 months and never matched" is gold for cleaning up rule sprawl.
• Cloud NAT. Managed outbound NAT for VPCs. The right way to give private workloads internet egress without giving them public IPs. Pair with VPC SC egress rules to constrain what they can reach.

Compliance & governance

• Assured Workloads. A folder inside your normal commercial GCP organization that auto-enforces a compliance regime - FedRAMP Moderate / High, IL2 / IL4 / IL5, ITAR, HIPAA, CJIS, Canadian Protected B, and others. Google enforces the constraints automatically: data-residency, personnel access, encryption, and which services are even available in the folder. The in-place alternative to running in a separate GovCloud-style tenant.
• Compliance Reports Manager. Self-service portal for downloading current attestation reports - SOC 1/2/3, ISO 27001/17/18, PCI DSS, HIPAA, FedRAMP, IRAP, BSI C5, and many more. The single place to pull the documents auditors and procurement teams ask for.
• Risk Manager. Generates an evidence-based Risk Report from SCC findings, posture state, and config - used for cyber-insurance underwriting (Munich Re, Allianz, Coalition) and as input to internal risk programs.
• Policy Controller (Anthos). Kubernetes admission control based on OPA Gatekeeper, packaged with curated policy bundles for CIS Benchmarks, NIST SP 800-190, PCI DSS, and others. Runs across GKE, Anthos, and attached EKS/AKS clusters.

Posture & governance

• Organization Policy Service. Constraint-based guardrails applied at organization / folder / project scope. Disable creation of external IPs, restrict allowed regions, enforce CMEK, require Shielded VMs, deny public GCS access at the org level. Inheritance flows down; explicit exceptions are themselves auditable.
• Policy Intelligence. See identity section - IAM Recommender, Policy Analyzer, Policy Troubleshooter, Policy Simulator.
• Recommender. Cross-resource recommendations - over-provisioned Compute Engine, idle service accounts, unused project IAM grants, sub-optimal firewall rules. Most engineers don't realize how much risk reduction the unused-SA recommender alone produces.
• Cloud Asset Inventory. The org-wide inventory of every resource, IAM binding, and Org Policy, with 35-day history. Queryable in real time; exportable to BigQuery for analytics. The "what does my GCP environment actually look like right now?" answer.
• Security Health Analytics. The misconfiguration scanner inside SCC. CIS GCP Foundations benchmark coverage plus Google's own findings catalog; runs continuously and at every config change. Free in SCC Standard, deeper coverage in Premium/Enterprise.

Container & Kubernetes security

• Binary Authorization. Admission-control policy that requires container images to be signed by trusted attestors before being deployed to GKE, Cloud Run, or Anthos. Enforces SLSA build provenance and signed-attestation chains end-to-end. The right answer to "how do we make sure only images that came out of our trusted pipeline can run in prod?"
• Artifact Registry vulnerability scanning. Continuous CVE scanning of container images, Maven, npm, Python, Go, and Helm artifacts. Findings surface in SCC; pair with Binary Authorization to block deployment of images above a CVSS threshold.
• GKE Security Posture. GKE's built-in posture-management surface - cluster configuration findings, workload misconfigurations (privileged pods, hostPath mounts), and image vulnerabilities, all without an extra agent. Free for Standard clusters; deeper insights in Autopilot.
• Workload Identity for GKE. Maps Kubernetes ServiceAccounts to GCP service accounts via OIDC. Pods get scoped, short-lived GCP credentials automatically - no metadata-server hopping, no host-mounted SA keys. The default-on choice for new GKE workloads since 2020.

Reference architecture - GCP landing zone

A defensible GCP landing zone has four moving pieces - the hierarchy, the org policies, the perimeters, and the central log sink. Get these right and most other controls compose cleanly on top.

1. The org / folder / project hierarchy

The hierarchy is the unit of blast radius. A typical pattern:

• Organization (your domain - example.com)
  • Bootstrap folder - Terraform state buckets, central seed projects, break-glass admin accounts.
  • Common folder - shared services projects: VPC host, DNS, central monitoring, central logging.
  • Security folder - security-team-owned projects: SCC, Chronicle, log sink destination, SIEM, security tooling.
  • Production folder - workload projects, one per app/service or per environment. Inherits stricter Org Policies (no external IPs, CMEK required, Shielded VMs).
  • Non-production folder - dev/staging/qa workload projects. Looser policies; smaller blast radius; no production data.
  • Sandbox folder - engineer exploration. Hard cost limits. No production data. Allowed to break.

Use the landing-zones page for the general pattern; this is the GCP-specific variant.

2. Organization Policy constraints applied at the top

Apply these as a baseline at the org or top-level folder, override down where exceptions are justified:

• constraints/iam.allowedPolicyMemberDomains - restrict IAM grants to your own Cloud Identity domain.
• constraints/iam.automaticIamGrantsForDefaultServiceAccounts - disable the legacy Editor role on default Compute Engine and App Engine SAs.
• constraints/iam.disableServiceAccountKeyCreation - block creation of long-lived SA JSON keys; force Workload Identity Federation.
• constraints/compute.requireShieldedVm - require Shielded VMs everywhere.
• constraints/compute.vmExternalIpAccess - deny external IPs by default; allow only for explicit projects.
• constraints/storage.publicAccessPrevention - block GCS public access org-wide.
• constraints/storage.uniformBucketLevelAccess - disable per-object ACLs.
• constraints/sql.restrictPublicIp - no public IPs on Cloud SQL.
• constraints/gcp.resourceLocations - restrict resource creation to approved regions for residency.
• constraints/gcp.restrictCmekCryptoKeyProjects - restrict which projects' CMEK keys can be used.

3. VPC Service Controls perimeters

One perimeter around production. Inside the perimeter: BigQuery, Cloud Storage, Pub/Sub, Cloud KMS, Cloud SQL, every service holding regulated data. Ingress rules permit specific identities from specific networks; egress rules permit specific outbound paths (e.g., to a partner project). The perimeter denies everything else, regardless of IAM. See the deep-dive for design patterns.

4. Central log sink to a dedicated security project

One aggregated log sink at the org level, routing all Admin Activity + Data Access + System Event + Policy Denied audit logs into a single security-folder project. From there: split sinks to BigQuery (for analytics), Cloud Storage with Bucket Lock (for tamper-evident retention), Pub/Sub (for streaming to Chronicle or an external SIEM), and a Cloud Logging bucket (for short-term operational queries). The security project is the only place humans hold the IAM to read these logs.

Top 10 GCP security misconfigurations

The findings every CSPM tool will surface in any GCP environment that hasn't been actively hardened:

1. Public GCS bucket. Bucket-level IAM granted to allUsers or allAuthenticatedUsers. The most common cause of accidental data exposure on GCP. Fix: enforce constraints/storage.publicAccessPrevention at the org level; audit existing buckets with Asset Inventory.
2. allUsers / allAuthenticatedUsers IAM bindings. Not limited to GCS - Pub/Sub topics, Cloud Functions, Cloud Run services, and BigQuery datasets can all be granted to the public principals. Search the org's IAM bindings for these and treat each match as an incident.
3. Default Compute Engine SA at Editor. Legacy projects auto-grant roles/editor to the default Compute Engine SA. Every workload that uses it inherits ~almost-everything. Fix: enable the automatic-IAM-grants constraint, assign least-privilege SAs per workload, deprecate the default.
4. No VPC Service Controls. Data sits in BigQuery and GCS protected only by IAM. A single compromised credential is sufficient to exfiltrate. Add a perimeter even if it starts in dry-run mode.
5. Project-level over-privilege. Engineers granted roles/editor or roles/owner on whole projects "to unblock work." Editor and Owner are essentially admin in GCP's model. Replace with task-specific roles (custom or curated predefined).
6. No audit log sinks. Admin Activity logs flow to Cloud Logging but aren't routed to long-term storage; Data Access logs aren't enabled at all. When you need them for IR, they're 30 days old at best. Fix: aggregated sink at org level on day one.
7. Exposed Firebase / public Firestore rules. Firebase projects auto-create Firestore and Realtime Database with permissive default rules. Whole Firestore exposures are routinely discovered via security research tooling. Audit the rules file on every Firebase project.
8. Cloud Function / Cloud Run with --allow-unauthenticated. Deploys with public-internet invocation. Sometimes intentional (a public API); often not. Audit per project; for non-public services, require IAP or IAM-based invocation.
9. Hardcoded SA JSON keys in code. The single biggest preventable GCP incident class. The fix is Workload Identity Federation for everything outside GCP, Workload Identity for everything inside GKE, and the SA-key-creation constraint everywhere else.
10. IAM "Owner" sprawl. Org or folder Owner roles granted as a convenience, never revoked. Owner can grant any IAM, modify Organization Policies, and self-escalate trivially. Treat Owner as break-glass-only; the daily-driver role is something tighter.

GCP-specific attack paths

The techniques offensive operators reach for in real GCP engagements. For the broader cloud-pentesting view see cloud-pentesting.html → GCP section.

• Service account impersonation via iam.serviceAccounts.actAs. A principal that can actAs a service account can effectively become it. Privilege escalation often hides in non-obvious bindings - roles/iam.serviceAccountUser at the project level is wide. Map every grant of this permission via Policy Analyzer.
• Deployment Manager / Cloud Build privilege escalation. Historically, Deployment Manager ran with a service account that had Editor on the project - anyone who could submit a Deployment Manager template could escalate. Cloud Build has similar dynamics with its default SA. Audit which SAs these services run as in your projects.
• Compute metadata SSH key injection. A principal with compute.instances.setMetadata can add an SSH key to instance metadata, then SSH in as a privileged user. Bypasses OS Login and any normal user-access controls. Tightly scope setMetadata; require OS Login org-wide; monitor metadata changes.
• GCS bucket takeover via deleted bucket. Bucket names are global. A bucket referenced in a script that gets deleted can be claimed by an attacker, who can then serve attacker-controlled content to anything still pointing at the URL. Watch for orphaned bucket references in code.
• IAM Conditions bypass. Conditional IAM bindings are powerful but easy to misconfigure - a condition that evaluates false for "request.time < some-past-date" effectively becomes an unconditional grant. Review every conditional binding with Policy Analyzer.
• Default Compute SA abuse from compromised workload. A compromised application running on a Compute VM or in Cloud Run that uses the default SA inherits Editor-class permissions. The remediation is structural - kill the default SA grants - but in the wild, this is the most common cloud-side post-exploitation path.
• Tooling - GCPBucketBrute, gcphound, hayat. Common offensive tooling for enumeration, IAM-graph traversal, and posture assessment. The first two are what your red team will run; the third is a Bash auditing baseline.

VPC Service Controls deep-dive

VPC SC is the GCP security primitive that has no clean equivalent at AWS or Azure. Understanding it well is the highest-leverage thing a GCP security engineer can do.

What it actually solves

IAM answers "who is allowed to call this API?" VPC SC answers "from where, and where can the data go?" The classic exfiltration scenario: an attacker compromises a workload with legitimate IAM permissions on a BigQuery dataset; the attacker queries the dataset and copies the result to a personal GCS bucket in their own project. IAM does not stop this - the call is authorized. VPC SC stops it - the perimeter denies the cross-perimeter API call regardless of IAM.

The threat model VPC SC defends against:

• Credential theft. A compromised SA key or hijacked session can't move data outside the perimeter.
• Insider exfiltration. A privileged user can't copy regulated data to a personal project.
• Misconfigured public access. A bucket accidentally granted to allUsers is still inaccessible from outside the perimeter - defense in depth on top of IAM.
• Cross-project lateral movement. A compromise in one project can't reach data in a different project that's inside a different perimeter.

How to design perimeters

The hard part of VPC SC is not the technology - it's the design. The mental model that works:

• One perimeter per data domain, not per project. Group projects that legitimately share data into a perimeter. A production analytics perimeter might span 15 projects that all read/write the same BigQuery datasets. Cross-perimeter access requires explicit ingress/egress rules.
• Start with dry-run mode. A perimeter in dry-run logs every violation without enforcing. Run dry-run for 2-4 weeks before enforcing; you will discover legitimate flows you didn't know existed (CI builds, monitoring agents, support tooling).
• Use perimeter bridges or ingress/egress rules - not both. Bridges connect perimeters bidirectionally for specific services; ingress/egress rules express richer conditions (specific identities, specific networks, specific services, specific methods). Newer designs prefer ingress/egress rules.
• Cover every restricted service. VPC SC works at the service level - Cloud Storage, BigQuery, Pub/Sub, Cloud KMS, Cloud Logging, and others are perimeter-aware. Services not on the supported list can leak data across the boundary; treat the list as an evolving feature.
• Plan for break-glass. A misconfigured perimeter can block legitimate admin access. Maintain a separate identity that can edit the Access Policy and is monitored heavily, used only when the primary admin path is broken.

Ingress and egress rules

The composition primitive is:

• Ingress rule: "Identity X, calling from network Y, can reach service Z inside the perimeter via methods M." Example: the build pipeline's SA, from the build VPC, can call storage.objects.create on production GCS.
• Egress rule: "Identity X inside the perimeter can call service Z outside the perimeter via methods M." Example: the production data pipeline can write to a partner's Pub/Sub topic in a partner project for daily exports.

Every rule is auditable and shows in Policy Denied audit logs when it would have allowed something - the asymmetric value of VPC SC is that everything blocked at the perimeter is logged, even if no other detection fires.

GCP service comparisons

Quick reads on where the GCP-native option lands vs the leading alternative.

By discipline - GCP anchors on every page

Most readers come to this page wanting the GCP take on a discipline they already know. The cross-references below jump straight to the GCP section on each page:

• IAM & Identity on GCP - Cloud IAM, custom roles, conditions, Workload Identity Federation, IAM Recommender.
• Zero Trust on GCP - BeyondCorp Enterprise, IAP, Access Context Manager, Endpoint Verification.
• Network Security on GCP - VPCs, firewall rules, Cloud Armor, Cloud NGFW Enterprise, Cloud IDS, PSC.
• Data Security on GCP - Cloud KMS, EKM, Confidential Computing, Sensitive Data Protection, VPC SC.
• Vulnerability Management on GCP - Artifact Registry scanning, OS Config Patch, SCC vulnerability findings.
• Detection Engineering on GCP - Event Threat Detection, Chronicle YARA-L rules, audit-log analytics in BigQuery.
• Incident Response on GCP - Cloud Audit Logs forensics, disk snapshots, Live Forensic, SA-key revocation playbooks.
• Compliance on GCP - Assured Workloads, Compliance Reports Manager, Risk Manager, FedRAMP and IL pathing.
• GCP pentesting - enumeration, IAM-graph traversal, exfil testing, gcphound + GCPBucketBrute walkthroughs.
• Kubernetes on GCP (GKE) - Workload Identity, GKE Security Posture, Binary Authorization, Confidential GKE.
• Serverless on GCP - Cloud Run and Cloud Functions IAM, ingress controls, VPC SC integration.
• Landing Zones on GCP - org/folder/project hierarchy, central log sink, baseline Org Policies.

GCP certifications

Google's security-relevant certification ladder is shorter than AWS's or Azure's, and the Professional Cloud Security Engineer remains the credential for the role. The pragmatic sequence:

• Cloud Digital Leader. Foundational business-and-tech overview; optional unless your background is non-technical.
• Associate Cloud Engineer. The hands-on GCP fundamentals exam. Useful even for security-focused engineers because the IAM, networking, and operations material is the substrate every security decision sits on.
• Professional Cloud Security Engineer (PCSE). The flagship - IAM design, data protection, network security, compliance, incident response. Two hours, scenario-heavy. Recertify every two years. The headline credential for a GCP security role.
• Professional Cloud Architect (PCA). Adjacent - covers security as one pillar of architecture. Useful for senior security engineers expected to participate in architecture review.

For the cross-cloud certification roadmap, see Certifications.

GCP-native vs third-party

The honest take on where Google's first-party tooling outperforms the market, and where the third-party CNAPP / SIEM / ZTNA still wins.

Where GCP-native wins

• VPC Service Controls. No third-party can replicate it; it operates at the Google service edge, not the network edge.
• BeyondCorp Enterprise. If most internal apps live on GCP, IAP + ACM beats bolting on a third-party ZTNA - simpler, cheaper, lower-latency.
• Encryption-by-default. The "we forgot to encrypt the bucket" finding doesn't exist on GCP. The opt-out is harder than the opt-in.
• Assured Workloads. In-place compliance regimes (FedRAMP / IL / ITAR / HIPAA) without separate-tenant pain.
• Chronicle SecOps. Flat-fee SIEM pricing alone is a competitive moat at high data volumes.

Where third-party still wins

• Multi-cloud CNAPP. Wiz, Orca, and Prisma Cloud see across AWS + Azure + GCP with a single graph. SCC only sees GCP and the connectors Google chooses to build.
• Cross-cloud detection engineering. If the workload spans clouds, the SIEM needs to as well. Chronicle has improved on this, but Splunk and Sentinel still beat it for highly heterogeneous estates.
• Privileged-access management. CyberArk, BeyondTrust, and Delinea still beat any cloud's first-party offering for credential vaulting and session recording at enterprise scale.
• Vendor-risk / GRC platform. SCC tracks GCP controls, not the rest of your business. GRC platforms like Vanta, Drata, ServiceNow GRC, and OneTrust are still the system of record.

Further reading

Google primary sources

• Google Cloud Security Blog
• Google security overview whitepaper
• GCP Architecture Framework - Security pillar
• Security Foundations Blueprint
• Google Cloud Compliance Center
• Google Threat Intelligence (Mandiant) blog
• Google Cloud Next - session archive

Community & offensive references

• hackingthe.cloud - GCP section
• GCPBucketBrute (Rhino Security Labs)
• gcphound - IAM graph enumeration
• hayat - auditing tool
• gcp_firewall_enum
• MITRE ATT&CK - GCP matrix

Related CSOH pages

• AWS Security - the complete guide
• Azure Security - the complete guide
• Cloud Security Comparison (AWS vs Azure vs GCP)
• Shared Responsibility Model
• Landing Zones
• CSPM vs CNAPP
• Cloud Pentesting
• Detection Engineering
• Glossary

FAQ

What is VPC Service Controls?

VPC Service Controls is a logical perimeter around Google-managed services that prevents data movement across the boundary regardless of IAM. A compromised credential inside the perimeter cannot copy data to a personal GCS bucket outside the perimeter, even with full IAM permissions, because the perimeter denies the API call at the service edge. There is no AWS or Azure equivalent that operates at the same layer; this is the single most distinctive primitive in GCP security.

Should I use Security Command Center Premium or Enterprise?

Standard is free and gives you Security Health Analytics and a basic posture view. Premium adds Event Threat Detection, Container Threat Detection, Web Security Scanner, and attack-path analysis. Enterprise is Premium plus the full Chronicle SecOps SIEM/SOAR stack with Mandiant threat intelligence, billed on data ingest. Pick Premium if you already have a SIEM you trust; pick Enterprise if you want Google's SecOps stack to be your SIEM.

How does Workload Identity Federation work?

Workload Identity Federation lets workloads outside GCP - on AWS, Azure, GitHub Actions, Kubernetes, or anything that issues OIDC tokens - assume a GCP service account without a long-lived service-account JSON key. The external identity provider issues a signed token; GCP validates it against a workload identity pool configuration; GCP returns a short-lived access token for a specific SA. It is the right answer to "how do I avoid SA-key leaks?" and is the GCP equivalent of AWS IAM Roles Anywhere or Azure Workload Identity.

What's Chronicle vs Splunk?

Chronicle (now Google SecOps, inside SCC Enterprise) is Google's cloud-native SIEM with flat-fee ingest pricing, YARA-L detections, and tight integration with Mandiant threat intel. Splunk is the incumbent SIEM with the deepest ecosystem of integrations and the most mature search language (SPL), but per-GB ingest pricing that scales painfully at high volume. Chronicle wins on TCO and on Google-cloud-native data; Splunk wins on third-party connector breadth and search flexibility.

Is the default Compute Engine service account a problem?

Yes. By default every Compute VM and Cloud Run service in a project runs as the Compute Engine default SA, which historically has the project Editor role. Editor is roughly "modify almost anything in the project" - including reading data and impersonating other SAs. Newer projects have a constraint that demotes the default SA, but legacy projects still have Editor. Fix: enable constraints/iam.automaticIamGrantsForDefaultServiceAccounts, bind every workload to a least-privilege SA, and treat the default SA as deprecated.

How does BeyondCorp relate to Zero Trust on GCP?

BeyondCorp is Google's internal zero-trust model from 2011, productized as BeyondCorp Enterprise. It pairs Identity-Aware Proxy (IAP) for context-aware access to internal apps with Access Context Manager for policy. The model: never trust the network, always verify identity + device + context per request. GCP customers can adopt the same pattern - IAP fronting internal apps, ACM defining the policy, Endpoint Verification proving device posture - without buying a third-party ZTNA. See the zero-trust page.

What is Assured Workloads, and when do I need it?

Assured Workloads carves out a folder of compliance-controlled projects inside your commercial GCP organization, with Google automatically enforcing the matching constraints (data-residency, personnel access, encryption, service availability). Pick a regime (FedRAMP Moderate/High, IL2/IL4/IL5, ITAR, HIPAA, CJIS, Canadian Protected B). Use it whenever you have a regulated workload that needs those constraints; it's the in-place alternative to a separate GovCloud-style tenant.