GCP Cloud Security

Same Shared Responsibility, Different Vocabulary

Everything from "Cloud Security Fundamentals" still applies: the customer always owns data and access configuration. GCP just uses its own terminology and resource model, and this lesson maps the AWS/Azure concepts from the previous lesson onto GCP's equivalents.

The GCP Resource Hierarchy

Organization
 └── Folder (optional, for grouping)
      └── Project
           └── Resources (VMs, buckets, etc.)

IAM policies set at a higher level (Organization, Folder) are inherited by everything beneath them — a permissive policy set at the Organization level silently applies to every project under it, which is why the resource hierarchy itself is a security control, not just an organizational convenience.

GCP IAM: Roles, Not Just Policies

GCP IAM grants roles (bundles of permissions) to members (users, groups, service accounts) on a resource. Three role types:

Cloud Storage (GCS) Buckets: GCP's Public-Bucket Problem

A GCS bucket with allUsers or allAuthenticatedUsers granted any role is publicly (or internet-authenticated-user) readable — the direct GCP equivalent of AWS's classic public S3 bucket misconfiguration, and just as common a source of real breaches.

Service Account Keys: The GCP Equivalent of Leaked AWS Access Keys

A GCP service account can have downloadable JSON key files — if one leaks (committed to a public repo, left on a laptop), it grants whatever that service account can do, indefinitely, until manually revoked. Workload Identity (mapping a Kubernetes service account to a GCP service account without ever generating a downloadable key) eliminates this entire class of leak by design — directly analogous to preferring IAM roles over long-lived AWS access keys.

VPC Service Controls: Perimeter Defense for Data Exfiltration

Even with correct IAM, a compromised, over-permissioned identity could still exfiltrate data across project boundaries (e.g. copying data from a sensitive project's bucket to an attacker-controlled project). VPC Service Controls creates a security perimeter around a set of GCP resources, blocking data movement across that perimeter's boundary regardless of IAM permissions — a defense-in-depth layer independent of identity.

Cloud Audit Logs: GCP's CloudTrail Equivalent

Cloud Audit Logs record who did what, where, and when across GCP services — Admin Activity logs (always on, can't be disabled) and Data Access logs (must be explicitly enabled per service, since they can be extremely high-volume). Reviewing these is the same "audit evidence" concept from the earlier GRC lesson, applied to cloud infrastructure specifically.

Common Pitfalls

• Granting basic roles (Owner/Editor) in production instead of scoped predefined or custom roles
• Downloading and distributing service account key files instead of using Workload Identity
• Assuming IAM alone is sufficient without VPC Service Controls for genuinely sensitive data perimeters
• Forgetting that Data Access audit logs are off by default and must be explicitly enabled per service