Google Cloud Platform (GCP) has a different design philosophy from AWS or Azure: hierarchical resource management with projects as the primary isolation unit, IAM that’s simpler in some ways and more powerful in others, and tooling that reflects Google’s internal infrastructure heritage. This module covers GCP’s security model and the practical hardening checklist.
The resource hierarchy
ORGANIZATION (your company's GCP root)
└─ FOLDER (e.g., "Production")
└─ FOLDER (e.g., "App-Team-A")
└─ PROJECT (e.g., "app-prod-12345")
└─ RESOURCE (Compute Engine VM, GCS bucket, etc.)
Permissions inherit downward. Granting a role at Organization scope = role on every project in the org. Project is the primary isolation boundary — separate billing, separate API enablement, separate IAM policy.
IAM model
- Members: Google accounts, service accounts, Google groups, Cloud Identity domains, allAuthenticatedUsers (any Google account), allUsers (anyone)
- Roles: bundles of permissions. Three types:
- Basic roles (legacy) — Owner, Editor, Viewer. Avoid; too broad
- Predefined roles — service-specific (e.g., Cloud SQL Admin, Storage Object Viewer)
- Custom roles — define your own permission set
- Conditions: attribute-based access conditions (e.g., grant only during business hours, only from specific IPs)
- IAM bindings attach members to roles at a specific resource scope
Service accounts — the most-confused element
Service accounts are GCP’s machine identities. Patterns:
- Default service accounts — auto-created with each service; typically over-permissioned. Disable or restrict
- Custom service accounts — create per-workload with narrow roles
- Service account impersonation — short-lived credential generation; preferred over key files
- Workload Identity (GKE) — pods authenticate as Google service accounts via cluster identity. Eliminates service account keys
- Workload Identity Federation — external identities (AWS IAM, GitHub Actions OIDC, etc.) authenticate to GCP without service account keys
Service account keys are dangerous
JSON key files are long-lived credentials. Compromise = full impersonation of the SA. Prefer:
- Workload Identity for GKE
- Workload Identity Federation for CI
- Service account impersonation for human users
- If keys are unavoidable: rotate every 90 days, store in Secret Manager, never in git
Network security
- VPC firewall rules — default-deny inbound from 0.0.0.0/0; explicit rules allow specific ports
- Hierarchical firewall policies — at Organization or Folder; mandatory-allow/deny rules that override project-level
- VPC Service Controls — perimeter around services; data exfil prevention. Critical for production data plane
- Private Google Access — VMs without public IPs reach Google APIs over backbone
- Identity-Aware Proxy (IAP) — auth at Google’s edge for HTTPS apps; alternative to VPN
- Cloud Armor — Google’s WAF + DDoS
Cloud Storage (GCS) hardening
- Disable public access (uniform bucket-level access; remove allUsers/allAuthenticatedUsers bindings)
- Versioning + retention policies for important buckets
- Customer-managed encryption keys (CMEK) via Cloud KMS for sensitive data
- VPC Service Controls perimeter for data-at-rest plane
- Audit logs (Data Access logs) enabled for sensitive buckets
- Signed URLs with short TTL for time-bounded access
Cloud SQL hardening
- Private IP only (no public IP) — connect via Cloud SQL Auth Proxy from authorized hosts
- IAM authentication preferred over passwords
- Encrypted at rest (default) + CMEK for sensitive
- SSL/TLS required for connections
- Authorized networks tightly scoped if public IP unavoidable
- Automated backups + point-in-time recovery
- Cloud SQL Insights for query monitoring
GKE security
GKE-specific controls:
- Private cluster — control plane on private IP
- Workload Identity — pods authenticate to Google APIs via cluster identity, no service account keys in pods
- Binary Authorization — admission control requiring signed images
- GKE Sandbox (gVisor) — isolation for untrusted workloads
- Network policy — pod-to-pod traffic restrictions
- Confidential GKE Nodes — encrypted memory at hardware level (AMD SEV)
- Container-Optimized OS — minimal, hardened node OS
Cloud KMS
- Customer-managed encryption keys for storage, SQL, BigQuery, Compute Engine disks
- HSM-backed keys for highest assurance (FIPS 140-2 Level 3)
- External Key Manager (EKM) — keys stored outside GCP if regulatory requires
- Key rotation policies — annual minimum
- Separation of duties — KMS admin separate from data admin
Logging — the GCP stack
- Cloud Audit Logs — Admin Activity (always on, free), Data Access (off by default, paid), System Event, Policy Denied
- VPC Flow Logs — packet-level network telemetry
- Firewall Rules Logging — per-rule logging when triggered
- Access Transparency — visibility into Google support access to your data
- Cloud Logging sinks — export to BigQuery, Cloud Storage, or Pub/Sub for downstream
Enable Data Access logs for sensitive services (KMS, Storage, BigQuery) — Admin Activity alone misses key forensic data.
🔐 Intermediate Module · Basic Tier
Continue reading with Basic tier (₹499/month)
You've read 30% of this module. Unlock the remaining deep-dive, quiz, and every other Intermediate module.
99+ modulesAll levels up to this tier
20-question quizzesUnlimited retries with explanations
Completion certificatesShareable on LinkedIn
4 more sections locked below
