Azure Secrets Blueprint
The Secrets Blueprint for Azure keeps the third-party credentials of every application encrypted in Git with SOPS under Azure Key Vault keys, one key per stage, and syncs them on merge into the application Key Vault of each stage, from where the External Secrets Operator delivers them to pods. It builds on the Azure Enterprise Baseline, which creates the keys in the security subscription. This overview section is public.
What it deploys
The blueprint is one repository, acme-azure-blueprint-secrets:
- one folder per stage (sandbox, dev, staging and prod) and one encrypted YAML file per application, with flat
KEY: valuepairs; - a pull request workflow that validates every file and dry-runs the sync, with the plan as a comment;
- a sync workflow that, on merge, writes each key of a changed stage as one Key Vault secret named
<app>--<KEY>; - access enforced by Key Vault role-based access control (RBAC): every engineer group can decrypt sandbox and dev, and only the platform leads and the DevOps leads can decrypt staging and prod.
The workflows sign in with a federated identity and run on the self-hosted runners of the Baseline, because the application vaults are reachable only through private endpoints. The blueprints page describes how blueprints build on the Baseline.
The complete Secrets Blueprint documentation for Azure is available to customers who hold it. Read the documentation overview for the concepts behind it, then sign in from the navigation bar to open the full Secrets Blueprint documentation, or contact BuiltForProd to purchase it.