External Secrets Operator
The External Secrets Operator copies values from an external secret store into Kubernetes Secrets and keeps them in step. The Azure Web App Blueprint uses it to bring the stage's application Key Vault into the cluster, so no secret value lives in Git or in the Helm chart.
What it does
A SecretStore, or the cluster-wide ClusterSecretStore, tells the operator how to reach a provider and how to authenticate. An ExternalSecret lists the remote keys to read and the target Kubernetes Secret to write, and the operator re-reads the store every refresh interval. The creation policy decides who owns the target Secret; the deletion policy decides what happens to it when the remote key disappears.
How BuiltForProd uses it
The external-secrets unit installs the operator's chart, version 2.6.0, into the external-secrets namespace on the system pool, with the service account external-secrets-sa. Its identity id-<prefix>-eso is federated with that service account and holds Key Vault Secrets User on the stage's application vault kv-acme-eus2-<stage>-app only. The ClusterSecretStore azure-kv, created by the ArgoCD unit once the operator's CRDs exist, reads that vault with Workload ID through its private endpoint.
The application chart defines two ExternalSecrets, both refreshed every hour, owned by the operator (creationPolicy: Owner) and kept if a remote key disappears (deletionPolicy: Retain):
| ExternalSecret | Remote keys | Written by |
|---|---|---|
blueprint-app-secrets | mongo--host, mongo--port, mongo--srv, redis--host, redis--port; optionally appinsights--connection-string | The mongo-cluster, managed-redis and app-insights units |
blueprint-app-app-secrets | <app>--<KEY> for each key in the chart's appSecrets.keys, with _ written as - | The Secrets Blueprint's sync workflow |
The pod reads both Secrets as environment variables. Neither holds a database password: the API reaches Cosmos DB and Managed Redis with Microsoft Entra tokens. Password keys (mongo--password, redis--password) are mapped only when a stage switches a data store to native or key authentication.
With the Secrets Blueprint. acme-azure-blueprint-secrets keeps application secrets encrypted with SOPS, one folder per stage. Its sync workflow decrypts them in CI and writes them to the application vault with the syncer identity, which the application vault grants Key Vault Secrets Officer. Within the refresh interval the operator copies a new value into the cluster; forcing an earlier refresh is an annotation on the ExternalSecret.
Terms you will see
| Term | Meaning |
|---|---|
| ClusterSecretStore | The cluster-wide connection to the application vault, named azure-kv. |
| ExternalSecret | The list of vault keys to copy and the Secret to write them to. |
| Refresh interval | How often the operator re-reads the vault, here one hour. |
<app>--<KEY> | The vault naming of an application secret from the Secrets Blueprint. |
| Deletion policy | Retain: a Secret survives when its remote key is removed. |
Where to read more
- Azure Web App Blueprint overview and Azure Secrets Blueprint overview.
- Key Vault for the vaults and their controls.
- SOPS for how secrets are encrypted in Git.