What you receive

You receive a working secret management path, from an encrypted file in Git to a secret in the application Key Vault of each stage, 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 sold with the Baseline in Full Deployment with Blueprints, or on its own as a Blueprint Deployment for customers who already run the Azure Enterprise Baseline. In both cases the BuiltForProd team deploys it. See blueprints for how the blueprints fit together and purchasing and licensing for the terms.

The repository

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

Item	What it does
.sops.yaml	Routes each stage folder to its own versioned Key Vault key, so sops picks the key from the file's path
dev/, staging/, prod/	One encrypted YAML file per application per stage; two example applications, sample and sample2, show the layout. A sandbox/ folder is added when the sandbox stage is opted in
.pre-commit-config.yaml	Refuses a commit that touches a stage file without a sops: block, plus YAML, private-key and end-of-file checks
.github/CODEOWNERS	Developers review sandbox and dev; platform leads or infrastructure admins review staging, prod and the tooling
.github/workflows/plan.yml	Secrets Plan: on a pull request, validates each stage and comments the dry run of its sync
.github/workflows/sync.yml	Sync Secrets to Key Vault: on merge, syncs the changed stages; by hand, one stage with dry run and prune switches
scripts/validate.sh	Fails a stage whose files are not encrypted, do not decrypt, are not flat, or still hold PLACEHOLDER
scripts/push-to-keyvault.sh	Decrypts a stage's files and writes each key as the secret <app>--<KEY>, only where the value changed

The example applications are there to be renamed or removed when you onboard your own; APPS in the push script lists the applications that sync. The repository carries the PolyForm Internal Use License in LICENSE.md.

What is set up for you

• .sops.yaml holding the versioned key URL of each stage key in your tenant, and every stage file encrypted with it.
• Your namespace and home region slug in both workflows (SECRETS_NAMESPACE and ENV), so they address kv-acme-eus2-<stage>-app.
• The repository secrets and variables the workflows read: the syncer's client ID, your tenant ID, the acme-core-security subscription and the runner labels.
• GitHub Environments named after the three stages; staging and prod require approval from the platform-leads or devops-leads team.
• Branch protection on main: a pull request with an approval, code-owner review and the three Validate & dry-run checks (— dev, — staging, — prod).

What comes from the Baseline and the Web App Blueprint

The blueprint creates no Azure resources of its own. It uses:

• From the Azure Baseline, in acme-core-security: the vault kv-acme-eus2-sec-sops with one key per stage, key-scoped Key Vault Crypto User grants for the Entra ID groups, and the federated identity id-acme-secrets-syncer with Crypto User on all four keys.
• From the Baseline's contract vault of each stage: the syncer's principal ID, published as platform--secrets-syncer-principal-id.
• From the Web App Blueprint, in each stage subscription it deploys: the private application vault, Key Vault Secrets Officer for the syncer on it, and the External Secrets Operator with the azure-kv ClusterSecretStore that reads it.
• The Baseline's self-hosted runners, which reach the application vaults through their private endpoints.

Read the architecture overview to see how the pieces connect.

The documentation

This documentation set: the architecture, the key topology and the vault naming convention, both workflows and both scripts, the syncer identity and the Environment protection, how workloads consume the secrets, day-2 procedures for editing, adding, removing and rotating secrets and applications, the governance model and the incident playbook.