GCP Security Fundamentals

IAM answers "who can do what" — it grants roles to principals on resources, and it's purely additive, so it only ever adds permissions. Org Policy answers "what's allowed at all across the organization" — it's a set of deny-style constraints applied at the org, folder, or project level that cap what's possible regardless of IAM. So effective access is the intersection: even a Project Owner with full IAM can't do something an Org Policy forbids. The classic example is the constraint that disables service account key creation — with it set, even an Owner can't export an SA key, closing the biggest GCP credential-leak vector org-wide. It's the same grant-versus-guardrail split as AWS IAM versus SCPs: IAM is the gas pedal, Org Policy is the speed limiter.

VPC Service Controls draws a perimeter around a set of GCP resources and projects so that requests crossing that boundary are blocked even if the caller has valid IAM permission. It defends against data exfiltration: the scenario where a compromised credential or a malicious insider with legitimate access to, say, BigQuery tries to copy the data out to a personal or attacker-controlled GCP project. IAM alone wouldn't stop that because the identity is authorized; the perimeter does, by denying the cross-boundary API call. You define Access Levels for sanctioned exceptions — corporate IP ranges, trusted devices via BeyondCorp, specific service accounts. You'd use it around sensitive data stores like BigQuery, Cloud Storage, and Spanner. It's GCP's signature control with no clean AWS equivalent, which is why it comes up a lot.

Workload Identity lets a GKE pod assume a GCP service account without any exported key file. You bind a Kubernetes service account to a GCP service account, and at runtime the pod's Kubernetes token is exchanged through the metadata server for a short-lived GCP access token for that service account. So the pod gets scoped, automatically-rotating credentials instead of a long-lived JSON key sitting in the container or a secret — eliminating the single most common GCP credential-leak vector. It's the GCP analogue of EKS IRSA or Pod Identity, and the security win is the same: no static keys to steal, leak, or forget to rotate, and identity scoped to the specific workload rather than the node.

First I confirm and scope: identify the bucket, what data it holds, and how it was made public — an ACL granting allUsers or allAuthenticatedUsers. I check access logs to see whether anyone external actually read objects while it was exposed, since that determines if this is a misconfiguration or a data-exposure incident. Then I remediate: remove the public ACL bindings and enable uniform bucket-level access so per-object ACLs can't reintroduce it, ideally enforced org-wide via the Org Policy constraints for uniform bucket access and restricting allowed IAM member domains. If sensitive data was exposed, it becomes an incident with notification considerations. Finally I close the gap with prevention — Org Policy to block public buckets and an SCC/automation alert so the next public bucket is caught or auto-remediated immediately.

Admin Activity logs record configuration and metadata writes — IAM changes, resource creation — and are always on and free. System Event logs record GCP-initiated changes, also always on and free. Data Access logs record reads and writes to user data within services — like reading an object or querying a table — and are opt-in because they can be very high volume and costly. You enable Data Access logging on sensitive services where you need to know who read what — Secret Manager, BigQuery, Cloud Storage holding sensitive data — because without it you can answer "who changed the config" but not "who actually read the data," which is exactly the question that matters in a data-exfiltration investigation. It's the GCP parallel to AWS CloudTrail data events being off by default.

Binary Authorization is an admission control that only lets images meeting a policy run on GKE or Cloud Run — typically requiring a cryptographic attestation that the image came from your trusted build pipeline and passed required checks. At deploy time the admission controller verifies the image has valid attestations from designated attestors, which sign images using cosign or Cloud KMS, and rejects anything unsigned or from an untrusted source. This stops a tampered or rogue image — say one an attacker pushed to the registry — from silently running, and enforces that only images built and signed through your governed process reach production. There's an audited break-glass for emergencies. It's the runtime enforcement of provenance, the same idea as the SLSA/cosign controls on the CI/CD side.

By default, Compute Engine VMs run as the default service account, which historically is granted the project Editor role — broad write access across most of the project. The risk is that compromising any VM, for instance via an application RCE or an SSRF that reads the metadata server, hands the attacker that VM's token, and with Editor that token can modify resources across the whole project — a single compromised box becomes project-wide compromise. It's the GCP version of an over-privileged EC2 instance role. The fixes are to not use the default SA, instead attaching a dedicated least-privilege service account per workload, restricting the metadata server exposure, scoping access scopes, and using an Org Policy to prevent default SA grants. Treat the VM's identity as something an attacker will steal and scope it accordingly.