Google Cloud Platform offers a comprehensive set of infrastructure, platform, and managed services. Like its competitors, it provides the tools to build secure environments. Also like its competitors, it is frequently misconfigured in ways that create significant security exposure. Understanding the GCP-specific patterns of misconfiguration helps security teams and cloud architects avoid the most common pitfalls.
GCP’s security model has its own concepts and defaults that differ from AWS and Azure. Teams that move workloads to GCP from other cloud providers, or that manage multi-cloud environments, need to understand GCP’s specific security controls rather than applying assumptions from other platforms.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
“GCP has its own distinct security model and its own characteristic misconfiguration patterns. The default compute service account permissions are particularly generous, and the relationship between GCP projects means that a misconfiguration in one project can have implications across the organisation. Teams migrating from AWS or Azure sometimes apply mental models that do not translate directly.”
IAM and Service Account Risks
GCP’s default Compute Engine service account is granted the Editor role at the project level. This means any Compute Engine instance that does not explicitly specify a service account will run with a highly privileged identity. An attacker who compromises a compute instance can use the default service account to read and modify resources across the entire project.
Service account key files, JSON credentials that allow impersonation of a service account, represent a significant risk when created and stored outside GCP’s managed infrastructure. Keys that are committed to source code repositories, stored in shared file systems, or distributed through configuration management are a common source of credential exposure.
Organisation-Level Misconfigurations
GCP organises resources in a hierarchy: organisation, folders, projects, and resources. IAM policies applied at higher levels in the hierarchy cascade downward. A policy applied at the organisation level applies to all projects. This means overly permissive policies applied at a high level create broad exposure across the entire environment.
Organisation policy constraints define guardrails that prevent specific configurations across all projects. Constraints that prevent public IP assignment, enforce uniform bucket-level access on Cloud Storage, or restrict service account creation to specific domains reduce the likelihood of misconfiguration at the project level. Many organisations deploy GCP without defining these constraints.
Cloud Storage Exposure
GCP Cloud Storage buckets can be made publicly accessible, either intentionally for public web content or unintentionally through misconfigured access controls. Uniform bucket-level access, which removes the ability to grant access to individual objects, simplifies the access control model and reduces the risk of individual objects being inadvertently made public.
Vulnerability scanning services for GCP environments should check storage bucket access controls, service account permissions, compute instance configurations, and network firewall rules against established best practice baselines such as the CIS GCP Foundations Benchmark.
Testing Your GCP Security Posture
If your organisation runs workloads in GCP and has not specifically reviewed the security configuration of the environment, getting a penetration test quote from a firm with GCP experience gives you a prioritised view of the most critical configuration gaps and the attack paths they enable.
