agentleFS
Sign inStart free
ai-enhanced-engineerai-enhanced-engineer/aiee-skills/skills/gcp-security-hardening/SKILL.md

gcp-security-hardening

Skill4 starsChanged 5 months agoMITView on GitHub

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.

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Key Benefits: No keys to rotate or leak, short-lived tokens (1h default), auditable access, scoped to specific identities.

    line 50

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

GCP Security Hardening

Defense-in-depth security patterns for Google Cloud Platform, emphasizing zero trust architecture and keyless authentication.

Core Principles

PrincipleImplementation
Least PrivilegeMinimal permissions, scoped to resources
Zero TrustVerify everything, trust nothing
Keyless AuthWorkload Identity, no service account keys
Defense in DepthMultiple security layers
Audit EverythingCloud Audit Logs enabled

IAM Critical Rules

  1. Primitive roles (Owner, Editor, Viewer) are too broad for production
  2. Prefer predefined roles over custom when possible
  3. Grant at resource level — not project level
  4. Review with IAM Recommender — removes unused permissions
  5. Enforce MFA — especially for privileged accounts
  6. 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:

SourceUse Case
GitHub ActionsCI/CD from GitHub
GitLab CICI/CD from GitLab
AWS / Azure ADCross-cloud access
KubernetesGKE 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:

  1. 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-PatternPattern
Claiming infrastructure exists based on describe successVerify exact bindings for the ticket's specific use case (4-step hierarchy)
Code complete but binding pending without documentationDocument split-work state explicitly, create follow-up ticket
Primitive roles (Owner/Editor/Viewer)Predefined roles at resource level
Service account key filesWorkload Identity Federation
Public Cloud SQL endpointsPrivate IP + VPC connector
Single DB user for all operationsSeparate migration/app/auth users (see reference.md)
Same-origin SHA256 without pinningPin expected hashes in repository for higher assurance
IAM audit scoped only to DB secretsEnumerate ALL secrets from staging YAML — JWT, Redis, platform secrets use different prefixes (app-${env}-{type} vs {name}-${env})
Inferring runtime deps from config fieldsVerify actual client usage (imports, instantiation) before claiming dependency
Trusting ticket blocker counts without validationValidate against codebase — counts frequently wrong

Critical Rules

  1. No service account keys — a leaked key file grants persistent access; use Workload Identity Federation
  2. Private IPs only — No public endpoints for data stores
  3. Encrypt at rest — CMEK for sensitive data
  4. Audit logs enabled — Data Access logs for compliance
  5. 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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free