How to Safely Store and Use Secrets

Secrets typically refer to sensitive data such as passwords, tokens, access keys that are necessary for the correct functioning of an application but must be hidden from unauthorized access.

For instance, developers should not see database passwords, including those for staging and production environments. They generally work locally and that suffices for their needs, though there are exceptions.

Additionally, there are infrastructure secrets, which are not required by the application to function but are used for creating and managing the infrastructure related to the application or otherwise.

It makes sense to separate secrets by these types because the approaches for integrating them can differ. For example, application secrets are often added during the deployment process and stored in specialized vaults like Vault.

When it comes to infrastructure secrets, there are different approaches:

1. You can use integration with the same vault for the tools used for deployment: Helm, Helmfile, Terraform. Here, the secrets are directly stored as paths: pass: ref+vault://databases/postgres/gitlab#DB_PASSWORD.

2. Another solution could be using Sops, which involves storing secrets in an encrypted form.

Regardless of the approach you choose, it is crucial to remember that under no circumstances should secrets be included in the code, and certainly not in public git repositories.

We had a case where SMTP data (AWS SES) was exposed on GitHub. We responded quickly, within half an hour, but it was already too late; the daily email quota (which is 500K) was successfully used up by spammers.