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 owner of the application is responsible for creating the secrets following the AWS secrets manager guidance and storing the sensitive values using AWS console. They are also responsible for ensuring the secrets are rotated periodically.

  • 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 26 April 2024. It needs to be reviewed again on 26 October 2024 by the page owner #cloud-platform .
This page was set to be reviewed before 26 October 2024 by the page owner #cloud-platform. This might mean the content is out of date.