Skip to main content

Secrets overview

We identify secrets as one of three kinds:

  • user secrets
  • system secrets
  • application secrets

User Secrets

These are any kind of secret that is owned by a specific user (eg. GitHub or AWS credentials). The user is responsible for securely managing these secrets, typically using a password manager, and they should not be shared with other individuals or used in applications.

System Secrets

These are secrets used in system components, usually configured by someone who manages, configures or supports the system. For example, when setting up an application CI pipeline, the credentials it uses to fetch the source code and push the produced artifacts to a repository are considered system secrets.

These should not be tied to an individual user (who might leave the organisation). Instead, machine users should be employed. The responsibility of managing these secrets securely lies with the owner of the system.

Application Secrets

These are the secrets that an application requires at runtime. Some examples are: API keys for third-party services, keys that applications might use to communicate with each other, database credentials, cookie encryption keys and so on.

This kind of secrets falls under the shared responsibility model:

  • the owners of the application are responsible for securely managing the secrets at rest (eg. using git-crypt to encrypt them alongside the source code) and also for managing access to the secrets once they’ve been added to an environment,

  • the Cloud Platform team, on the other hand, is responsible for ensuring the secrets remain secure inside the environment.

This page was last reviewed on 10 August 2021. It needs to be reviewed again on 10 November 2021 .
This page was set to be reviewed before 10 November 2021. This might mean the content is out of date.