What you receive

You receive a working secret management path, from an encrypted file in Git to a Secret Manager secret in each of your stage projects, together with the Git repository that runs it, customized for your organization, and the documentation to operate it. After handover your engineers own the repository and every secret in it.

How delivery works

The blueprint is part of Full Deployment with Blueprints, where it is one of the two blueprints chosen alongside the Baseline, or is deployed on its own as a Blueprint Deployment for customers who already run the Baseline. In both cases the BuiltForProd team deploys it. See blueprints for how the three blueprints fit together and purchasing and licensing for the terms. The code is licensed for your internal use.

The repository

acme-gcp-blueprint-secrets, where acme is your namespace:

Item	What it does
.sops.yaml	Routes each stage folder to its own Cloud KMS key, so SOPS picks the right key by path
dev/, staging/, prod/	One encrypted YAML file per application per stage; two example applications show the layout
.github/CODEOWNERS	Developers review sandbox and dev; platform leads or infrastructure admins review staging, prod and tooling
.github/workflows/plan.yml	On a pull request: validates each stage and dry-runs the sync, then comments the plan
.github/workflows/sync.yml	On merge to main: syncs the stages whose folder changed; by hand: one stage, with dry run and prune switches
scripts/validate.sh	Checks that every file is encrypted, decrypts, is flat and holds no PLACEHOLDER value
scripts/push-to-secretmanager.sh	Decrypts a stage's files and writes each key as a Secret Manager secret
.pre-commit-config.yaml	Refuses a commit that touches a plaintext stage file

The example applications, sample and sample2, ship with every value set to PLACEHOLDER, and the validation refuses them. Your real applications and values replace them before the first sync.

What is set up for you

• The three stage folders, each tied to its stage's key and its stage's project, acme-plat-dev, acme-plat-staging and acme-plat-prod.
• Your namespace, home region, GitHub organization and team handles in the configuration, the review rules and the workflows.
• GitHub Environments named after the three stages; staging and prod require approval from the platform leads or the DevOps leads before their jobs run.
• Branch protection on main that requires a reviewed pull request, review from Code Owners, and the three checks Validate & dry-run — dev, Validate & dry-run — staging and Validate & dry-run — prod.

Sandbox is opt-in. Once the web app infrastructure deploys a sandbox stage, the repository gains a sandbox/ folder, a fourth .sops.yaml rule, a fourth plan job, a sandbox Environment and a fourth required check. Nothing on the Google Cloud side changes, because the Baseline already provides it.

What comes from the Baseline

The blueprint uses pieces the GCP Baseline already creates in your organization:

• The four SOPS keys in the key ring acme-sops of acme-core-security, one per stage including sops-sandbox, with grants that limit staging and prod to the leads.
• The service account sa-acme-secrets-syncer in acme-core-security, which only this repository can become, from GitHub Environment runs only.
• Secret Manager admin for that account on each of the four plat projects, conditioned so that it never touches secrets whose ID starts with platform--.
• The sa-protection tag on that account, so an IAM deny policy stops anyone outside the platform pipelines and the platform leads from acting as it, signing as it or creating a key for it.
• The Google groups the key grants name.

The blueprint adds no infrastructure of its own. Read the architecture overview to see how the pieces connect, and SOPS keys for the Baseline's side.

The documentation

This documentation set: the system architecture and key topology, the repository layout, the SOPS configuration, the secret naming convention, both workflows and both scripts, the federation and the environment protection, day-2 procedures for editing, adding and removing secrets and applications, how workloads consume the secrets, the governance model and the incident playbook.

How it fits with the other blueprints

The Web App Blueprint reads Secret Manager through the External Secrets Operator, which may read every secret in its stage project, so a value this blueprint writes reaches the application's pods once the chart lists its key. The web app infrastructure writes its own connection values (mongo--*, redis--*) into the same Secret Manager; this repository never touches them.