🌎 GCP Security Model
Google Cloud's security model is informed by Google's own experience securing one of the world's most attacked internet properties. Google's BeyondCorp zero trust model — which eliminated the traditional VPN perimeter at Google internally — directly influenced GCP's identity-centric security architecture. GCP's resource hierarchy provides a clean structure for applying security controls at scale.
Resource Hierarchy
GCP organizes resources in a four-level hierarchy: Organization → Folder → Project → Resource. IAM policies and Organization Policy constraints are inherited downward, with more specific policies taking precedence.
- Organization: root node, tied to Google Workspace or Cloud Identity domain
- Folders: group projects by department, environment, or team
- Projects: the primary billing, API, and IAM boundary
- Resources: Compute instances, GCS buckets, BigQuery datasets, etc.
- Policies set at a parent are inherited by all children
Organization Policy Constraints
Organization Policies enforce guardrails across the entire GCP organization, preventing misconfigurations that violate security requirements — even for project owners.
constraints/compute.requireOsLogin— enforce OS Login on all VMsconstraints/storage.uniformBucketLevelAccess— disable per-object ACLsconstraints/iam.disableServiceAccountKeyCreation— prevent key downloadsconstraints/compute.restrictCloudArmor— enforce WAF usage- Custom constraints via Common Expression Language (CEL) for resource attributes
| GCP Unique Security Advantages | Customer Responsibilities |
|---|---|
| Hardware security: Titan chip for server identity and boot integrity | IAM policy design and least privilege |
| Global private network — traffic never leaves Google's backbone | Project structure and Organization Policy configuration |
| Default encryption at rest for all services (no configuration needed) | Application security and code vulnerabilities |
| BeyondCorp-inspired zero trust for GCP console access (Context-Aware Access) | GKE node pool configuration and workload security |
| Shielded VMs and Confidential Computing built into the platform | Data classification and DLP policies |
| Google's threat intelligence from global network visibility | VPC firewall rules and network segmentation |
🔑 GCP IAM & Identity
GCP IAM uses a binding model: you bind a member (identity) to a role (set of permissions) on a resource. This differs from AWS's policy document approach. Understanding service accounts — and especially moving away from service account keys toward workload identity federation — is the most important GCP IAM security practice.
IAM Members & Roles
- Google Account: individual human users (google.com accounts)
- Google Group: manage permissions for teams via group membership
- Service Account: non-human identity for applications and VMs
- Workload Identity: federate Kubernetes workloads to service accounts (no keys)
- Predefined Roles: 800+ curated roles per service (e.g., roles/storage.objectViewer)
- Custom Roles: combine specific permissions for least privilege
Service Account Security
Service account keys are JSON files containing private keys that never expire by default. They are one of GCP's highest-risk credential types and should be replaced with keyless alternatives wherever possible.
- Prefer Workload Identity Federation for external workloads (GitHub Actions, AWS, Azure)
- Prefer attaching service accounts to GCE VMs over downloading keys
- Set Organization Policy to disable service account key creation org-wide
- Use IAM Recommender to identify and remove excess permissions
- Service Account Impersonation: allow a human to act as SA without a key
gcloud IAM Binding Example
# Grant a service account read-only access to a specific GCS bucket (not the whole project) gcloud storage buckets add-iam-policy-binding gs://my-app-bucket \ --member="serviceAccount:[email protected]" \ --role="roles/storage.objectViewer" # Bind a user to a role at project level with a condition (only during business hours) gcloud projects add-iam-policy-binding my-project \ --member="user:[email protected]" \ --role="roles/compute.viewer" \ --condition='expression=request.time.getHours("America/New_York")>=9 && request.time.getHours("America/New_York")<=17, title=BusinessHoursOnly' # Use IAM Recommender to list recommendations for a service account gcloud recommender recommendations list \ --project=my-project \ --location=global \ --recommender=google.iam.policy.Recommender \ --filter="stateInfo.state=ACTIVE"
🌐 VPC Security & Network Controls
GCP's VPC is a global resource by default — a single VPC can span all regions without requiring peering. GCP's most distinctive network security feature is VPC Service Controls, which creates a security perimeter around GCP API access to prevent data exfiltration even through compromised credentials.
VPC Service Controls
VPC Service Controls (VPC SC) creates a perimeter around GCP managed services — restricting which identities can access which services, and from where. This is GCP's primary defense against data exfiltration.
- Perimeters define which projects can access which services (e.g., BigQuery, GCS)
- Access levels: allow based on IP range, device certificates, identity
- Ingress/egress rules: control cross-perimeter data flows
- Blocks exfiltration even if a credential is stolen (context matters)
- Dry-run mode: audit policy violations before enforcement
Cloud Armor & Shared VPC
Cloud Armor provides DDoS protection and WAF capabilities at Google's edge, while Shared VPC enables centralized network governance across multiple GCP projects.
- Cloud Armor: pre-configured WAF rules (OWASP CRS), adaptive protection (ML DDoS)
- Rate limiting and reCAPTCHA enterprise integration for bot management
- Shared VPC: host project owns the network; service projects use it — centralized firewall
- Hierarchical Firewall Policies: enforce rules at org/folder level before project-level rules
- Cloud NAT: outbound internet access for private VMs without public IPs
Firewall Intelligence
- Firewall rules use network tags or service account identifiers (not just IPs)
- Service account-based rules: allow SA_A to talk to SA_B — identity-based firewall
- Firewall Insights: identify overpermissive rules, shadowed rules, stale rules
- Private Google Access: reach Google APIs from private subnets without internet
- Cloud Private Service Connect: private access to GCP and third-party services
🔎 Security Command Center (SCC)
Security Command Center is GCP's native security management and data risk platform — analogous to AWS Security Hub or Microsoft Defender for Cloud. It aggregates findings across your GCP organization, provides asset inventory, and delivers threat detection through specialized detectors integrated with Google's threat intelligence.
SCC Standard vs Premium
- Standard (free): Security Health Analytics, Web Security Scanner (basic), asset inventory, IAM grants exported to BigQuery
- Premium: adds Event Threat Detection, Container Threat Detection, Virtual Machine Threat Detection, compliance posture, and attack path simulation
- Event Threat Detection: analyzes Cloud Logging in real-time using Google threat intelligence
- Container Threat Detection: runtime behavior analysis in GKE using eBPF
- VM Threat Detection: memory-based malware scanning without an agent
Findings & Integration
- Findings categorized: THREAT, VULNERABILITY, MISCONFIGURATION, OBSERVATION
- Mute rules: suppress known false positives with justification tracking
- Export to BigQuery for custom analytics and long-term retention
- Export to Pub/Sub for real-time SIEM integration (Splunk, Chronicle, Sentinel)
- Google Chronicle SIEM: native GCP SIEM built on planet-scale data infrastructure
SCC Premium Threat Intelligence Advantage
SCC Premium's threat detection capabilities are backed by Google's visibility into a significant fraction of the world's internet traffic through its DNS infrastructure, Search, Gmail, and Cloud operations. Event Threat Detection can identify C2 communications, cryptocurrency mining, and data exfiltration using threat intelligence that is updated in near-real-time from this global vantage point — a capability that third-party tools cannot replicate.
✅ GCP Security Best Practices
GCP security hardening follows the CIS GCP Foundations Benchmark and Google's own security best practices guide. Several GCP-specific capabilities — Binary Authorization, Confidential Computing, and Cloud KMS — provide security controls not available on other platforms.
| GCP Security Tool | AWS Equivalent | Azure Equivalent |
|---|---|---|
| Security Command Center | AWS Security Hub + GuardDuty | Microsoft Defender for Cloud |
| VPC Service Controls | No direct equivalent (AWS PrivateLink + VPC Endpoints are partial) | Azure Private Endpoints (partial) |
| Cloud KMS / Cloud HSM | AWS KMS / AWS CloudHSM | Azure Key Vault / Azure Dedicated HSM |
| Binary Authorization | AWS Signer + ECR image scanning | Microsoft Defender for Containers image signing |
| Confidential VMs / Confidential GKE | AWS Nitro Enclaves | Azure Confidential Computing / DCsv2 VMs |
| Cloud Armor | AWS WAF + AWS Shield | Azure Front Door WAF + Azure DDoS Protection |
| IAM Recommender | IAM Access Analyzer | Entra ID Access Reviews + Defender for Cloud recommendations |
Binary Authorization
Binary Authorization enforces a deploy-time policy that ensures only trusted, verified container images can run in GKE clusters. It integrates with CI/CD pipelines via attestors.
- Attestors sign images after passing security checks (scan, test, review)
- Policy requires attestations before allowing deployment to GKE
- Block unattested images from being deployed to production clusters
- Audit mode: log violations without blocking (use to baseline first)
Cloud Audit Logs
GCP's audit logging captures three categories of events. Correctly enabling all relevant audit logs — especially Data Access logs — is required for compliance and forensic investigation.
- Admin Activity: always on, no charge — resource creation, IAM changes
- Data Access: disabled by default; billable — who read/wrote what data
- System Event: Google-initiated changes — always on, no charge
- Enable Data Access audit logs at organization level for key services
- Export all logs to Cloud Storage for long-term retention and SIEM ingestion