Secrets and identity
Two vaults, three managed identities, and no standing human access. Secret names are listed here. Values never appear in documentation, chat, or a repository.
The vaults
Section titled “The vaults”| Vault | Resource group | Holds | Read by |
|---|---|---|---|
kv-ba-staging-app |
rg-ba-staging |
The application’s runtime secrets and the field-encryption master key dek-master |
The API at boot (every secret), the document builder through secret references, Terraform for the values it writes |
kv-ba-staging-tf |
rg-terraform |
What Terraform itself needs: the state encryption key, provider credentials for Atlas, Cloudflare and GitHub | CI through OIDC; an operator through scripts/fetch-kv-secrets.sh |
Application secrets
Section titled “Application secrets”ba-api reads its configuration from the vault at boot. The names follow its environment variable names with _ replaced by -, and are case-insensitive (ba-api/src/modules/config/Config.ts). Where each value comes from:
| Written by | Names |
|---|---|
The database layer |
MONGO-URL |
The aws layer outputs, set by hand |
S3-BUCKET, S3-REGION |
aws iam create-access-key for the bucket user, piped straight into the vault |
S3-ACCESS-KEY-ID, S3-SECRET-ACCESS-KEY |
| The document builder’s internal hostname | DOCUMENT-BUILDER-URL |
| The vendor licence, set by hand | SYNCFUSION-LICENCE (read by the document builder) |
| Copied from the previous deployment’s vault or 1Password | Ory, mail and the rest of the application’s names |
The document builder does not read the vault itself. The compute layer gives it Container Apps secret references (MongoDatabaseSettings__ConnectionString, AppSettings__Licences__Syncfusion) that resolve from the vault through the API’s identity.
Managed identities
Section titled “Managed identities”| Identity | Used by | Role |
|---|---|---|
id-ba-staging-api-kv |
Both apps | Key Vault Secrets User on kv-ba-staging-app |
id-ba-staging-api-dek |
The API | Key Vault Crypto User, to wrap and unwrap data-encryption keys with dek-master |
id-ba-staging-acr-pull |
The Container Apps environment | AcrPull on acrbastaging |
People
Section titled “People”Nobody has standing access to either vault. The operators group sg-ba-staging-platform-ops is eligible for Key Vault Secrets Officer and Key Vault Crypto Officer on the application vault through Privileged Identity Management. An operator activates a role for up to two hours with a reason and MFA:
scripts/kv-access.sh kv-ba-staging-app --roles both --reason "BAM-<n>: why"The activation emails the PIM admins. Full procedure: Writing or reading a secret by hand.
GitHub Actions signs in to Azure as the app registration ba-infrastructure-github-oidc with federated credentials for the infrastructure repo’s main branch, its pull requests and its infrastructure-production environment, and for environment ba-staging on ba-api and ba-document-builder-service. For AWS it exchanges the same GitHub token for the role ba-terraform-ci in the Sii management account, which steps into the bam-staging account. No service-principal password or registry password exists in GitHub or in a vault.
Repository settings that are not secrets: variables AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID, AWS_ROLE_ARN, TERRAGRUNT_SHA256 on ba-infrastructure.