Skip to content

Secretes and KeyVault

Secret storage

  • All secrets must be stored in Azure KeyVault and not in config files.
  • KeyVault should only store secrets. Non-secrets / general config should be stored in config files. Remember that you cannot know the value of a secret, meaning it's much easier to manage configuration in config files!

Secret access

  • Developers can list the keys in the KeyVault, but not the secrets themselves.
  • There should never be a need to manually read out a secret from a KeyVault.

Global vs Area KeyVault

  • Secrets are divided into global secrets, stored in a global KeyVault, and area specific secrets stored in Area-specific KeyVaults.
  • Each area have its own KeyVault, which only that area reads from.
  • Usage of the global KeyVault should be minimized, and before any new secrets are placed there should be a discussion with Victor and platform team.

Rotation and reuse

  • Secrets should be possible to rotate (i.e. update a password once per month or update a token signing key once per year). That means that some secrets need to be stored doubled, e.g. primary token and secondary token, and in code both tokens are treated as valid.
  • Secrets should not be reused between areas unless strictly necessary:
    • If two areas need to access the same 3rd party, if possible two sets of credentials should be created (one for each Area). I.e. multiple areas need access to Firebase, therefor they should have separate Firebase credentials.
    • If two areas need to encrypt/decrypt different information, they should use different secrets. E.g. there should not be a master key that is used for encrypting/decrypting many different things.

Environments

  • Secrets for local development are (as of 2024-08-29) stored in a local user secrets JSON file in git, but the vision is to move these to a common dev KeyVault.
  • There are separate KeyVaults for dev, stage and prod environments.
  • The dev, stage and prod KeyVaults should as much as possible contain the same set of secrets (e.g. if a key is in stage, it should also exist in dev/prod).
  • Secrets should not be reused between environments. This is especially important for production secrets, but also apply for dev and stage.

Naming

  • Give a good descriptive name to the secret.
  • The name used in KeyVault will be <ConfigurationSource>--<PropertyName>
  • It should be easy to understand what kind of secret it is, what it is used for, and if it belongs to a 3rd party by looking at its name in KeyVault. I.e. phoneplan-gigs-credential--ApiKey.
  • Secrets that belong to a 3rd party should either be prefixed with the 3rd party, or have the third party in the ConfigurationSource name, so that it's easy to understand what the secrets in a KeyVault are used for.