| name | gcp-security-hardening |
| description | GCP security hardening patterns including IAM best practices, Workload Identity Federation (WIF), zero trust architecture, binary authorization, and container security. Use for securing GCP resources, eliminating service account keys, or implementing defense in depth. |
| kb-sources | ["wiki/software-engineering/gcp-security-hardening"] |
| updated | "2026-05-20T00:00:00.000Z" |
GCP Security Hardening
Defense-in-depth security patterns for Google Cloud Platform, emphasizing zero trust architecture and keyless authentication.
Core Principles
| Principle | Implementation |
|---|
| Least Privilege | Minimal permissions, scoped to resources |
| Zero Trust | Verify everything, trust nothing |
| Keyless Auth | Workload Identity, no service account keys |
| Defense in Depth | Multiple security layers |
| Audit Everything | Cloud Audit Logs enabled |
IAM Critical Rules
- Primitive roles (Owner, Editor, Viewer) are too broad for production
- Prefer predefined roles over custom when possible
- Grant at resource level — not project level
- Review with IAM Recommender — removes unused permissions
- Enforce MFA — especially for privileged accounts
- Security keys for admins — phishing-resistant 2FA
Service Account Principles
- One per application — dedicated per application, not shared
- No user-managed keys — use Workload Identity
- Disable unused accounts — audit regularly
- Token Creator at project level enables impersonation of any SA
Workload Identity Federation
Eliminate service account keys by federating external identities:
| Source | Use Case |
|---|
| GitHub Actions | CI/CD from GitHub |
| GitLab CI | CI/CD from GitLab |
| AWS / Azure AD | Cross-cloud access |
| Kubernetes | GKE Workload Identity |
Key Benefits: No keys to rotate or leak, short-lived tokens (1h default), auditable access, scoped to specific identities.
WIF Validation Hierarchy
Verifying pool existence alone is insufficient — validate the full binding chain:
- Pool exists → 2. Provider exists → 3. Binding exists → 4. IAM roles assigned
Phase 3.5 Checklist Item: "Verify bindings, not just resources" — a pool returning success does NOT mean the binding for your specific provider/repo exists.
Anti-Patterns
| Anti-Pattern | Pattern |
|---|
Claiming infrastructure exists based on describe success | Verify exact bindings for the ticket's specific use case (4-step hierarchy) |
| Code complete but binding pending without documentation | Document split-work state explicitly, create follow-up ticket |
| Primitive roles (Owner/Editor/Viewer) | Predefined roles at resource level |
| Service account key files | Workload Identity Federation |
| Public Cloud SQL endpoints | Private IP + VPC connector |
| Single DB user for all operations | Separate migration/app/auth users (see reference.md) |
| Same-origin SHA256 without pinning | Pin expected hashes in repository for higher assurance |
| IAM audit scoped only to DB secrets | Enumerate ALL secrets from staging YAML — JWT, Redis, platform secrets use different prefixes (app-${env}-{type} vs {name}-${env}) |
| Inferring runtime deps from config fields | Verify actual client usage (imports, instantiation) before claiming dependency |
| Trusting ticket blocker counts without validation | Validate against codebase — counts frequently wrong |
Critical Rules
- No service account keys — a leaked key file grants persistent access; use Workload Identity Federation
- Private IPs only — No public endpoints for data stores
- Encrypt at rest — CMEK for sensitive data
- Audit logs enabled — Data Access logs for compliance
- VPC Service Controls — For sensitive projects
Static SPA Least-Privilege
Service accounts for static SPAs (nginx + Angular on Cloud Run) should NOT receive cloudsql.client. Grant only roles/logging.logWriter and roles/artifactregistry.writer. See infra-terraform skill for SA map exclusion pattern.
See reference.md for IAM Permission Hierarchy, Zero Trust/BeyondCorp components, network security, container security, CI binary verification, and least-privilege DB user patterns.
See examples.md for WIF Terraform modules, GitHub Actions workflows, secure Cloud Run, GKE hardening, and IAM audit configuration.
