Skip to main content

Secrets Management

We use Azure Key Vault for managing secrets.

  • Use cnp-module-key-vault terraform module to create key vaults.

  • Naming convention for keyvaults is {product}-{component}-{env}.

    Warning Name of the keyvault cannot exceed 24 characters, which means {product}-{component} length cannot be more than 15 characters

  • Your team will manage the secrets, use the CLI to write secrets as you won’t be able to see the vault in production, only write and list access is given out, if you’re unsure if a credential is correct you can just overwrite it with the correct one.

  • Use shared vaults ({product}-{env}) created through shared infrastructure repository if there are more secrets shared across multiple components in your product.

  • If any secrets are exposed in the open, raise a security incident, by reporting it to ‘Security Operations’, create a new secret, update the application configuration and revoke the old secret.

Setup application access.

  1. Applications running in Kubernetes use Azure Workload Identity to access secrets from keyvaults.
  2. We recommend using one workload identity per product / team.
  3. Managed Identity can be created by using the cnp-module-keyvault terraform module. Note: You need to run your infrastructure pipeline on each environment for this to be added
  4. Add AzureIdentity k8s resources to Flux.
  5. All base helm charts support configuring keyvaults to mount secrets on container file system using secrets-store-csi-driver-provider-azure.
  6. Applications should use properties-volume-nodejs or Spring Boot config tree to set secrets from file systems as environment variables.
This page was last reviewed on 16 May 2024. It needs to be reviewed again on 16 November 2024 by the page owner platops-build-notices .
This page was set to be reviewed before 16 November 2024 by the page owner platops-build-notices. This might mean the content is out of date.