GCP Network & Workload Identity

VPC firewall rules — global by default

GCP firewall rules apply at the VPC level, not per-subnet. They are stateful, allow-or-deny, and priority-ordered (lower number wins). Rules target by network tag, by service account, or by IP range. Defaults: deny all ingress, allow all egress.

• Target by service account is the modern best practice. Rules that say "allow port 443 to instances running as web-prod@my-project.iam.gserviceaccount.com" are tighter than tag-based rules — tags can be added by anyone with VM edit permission; service account assignment is gated by impersonation permissions.
• Hierarchical firewall policies apply at the org or folder level and evaluate before VPC rules. The org-wide guardrail layer, equivalent in role to AWS SCPs at the network layer.
• Cloud NGFW Enterprise adds L7 filtering, TLS inspection, and intrusion prevention. The upper tier; most workloads stay on VPC rules.

VPC Service Controls — perimeter around data

VPC Service Controls (VPC-SC) defines a service perimeter that wraps a set of GCP projects and API services. Within the perimeter, the services can talk freely. From outside the perimeter, even a fully authorized IAM identity is denied. This protects against IAM-credential-theft data exfiltration in a way IAM alone cannot.

VPC-SC is the most GCP-specific control on this page. AWS achieves overlapping outcomes with VPC endpoints + IAM condition keys; Azure with Private Endpoints + Storage firewalls. GCP packages it as a discrete product, which makes the operational story clearer but adds a moving piece.

Workload Identity Federation — no keys, ever

The classic way for non-Google workloads (a Lambda function in AWS, a GitHub Actions job, an on-prem Kubernetes pod) to authenticate as a GCP service account was to download a JSON key file and store it as a secret. That file is a long-lived credential. If it leaks, an attacker can use it indefinitely.

Workload Identity Federation (WIF) replaces this entirely. Instead of a downloaded key, the external workload presents an identity assertion (an OIDC token from AWS STS, a GitHub Actions OIDC token, an Azure AD token, etc.). GCP verifies the assertion against a configured workload identity pool, and issues a short-lived Google access token in exchange.

• No long-lived secrets live in the external system. The OIDC issuer is the trust anchor.
• Short-lived tokens (default 1 hour) make leaked tokens almost worthless.
• Per-issuer attribute conditions let you restrict which OIDC claims map to which service account: "only GitHub workflows in repository acme/payments-prod, only on the main branch, only with environment prod selected."
• Audit logging records the external identity along with the Google service account, so attribution is preserved.

Security Command Center — the view

Security Command Center (SCC) is GCP's centralized security platform. Two main capabilities:

• Posture & misconfig detection. Continuously scans GCP resources for misconfigurations against benchmarks (CIS, PCI, NIST). Surfaces public buckets, overly-permissive IAM bindings, missing logging.
• Threat detection. Container Threat Detection, Event Threat Detection (analyzes Cloud Logging for known-bad patterns), Web Security Scanner, Virtual Machine Threat Detection. Each feeds findings into the SCC pane.

SCC Premium and Enterprise add attack path analysis ("this misconfig + that IAM binding = reachable as 'public read' through this chain"), CIEM (cloud infrastructure entitlement management) for identity-permission analysis, and SOAR integration. The free tier is enough to catch the obvious misconfigurations; premium tiers are where the proactive analysis lives.