1

I am developing applications that require user secrets to function. These credentials should not be stored in source control due to security concerns. Instead, they need to be manually created by the user or generated via a deploy script, with the values kept separate from the source code.

I am looking for the best approach to securely manage and access these user secrets in a deployment environment. What are the recommended options and best practices for handling such sensitive information, ensuring it remains secure and accessible to the applications when needed?

Specifically, I would like to understand:

  1. What are the common strategies or tools used to store and manage user secrets securely outside of source control?
  2. How can these secrets be securely accessed by the applications during deployment or runtime?
  3. Are there any recommended techniques or patterns to automate the process of secret management and deployment while minimizing the risk of exposing sensitive information?

Any guidance or insights on the best practices, tools, and techniques for handling user secrets in a deployment scenario would be greatly appreciated.

Ewan
  • 113
  • 3

1 Answers1

0

The current practice for this is to use a secret vault. There are flavours of this, such as Azure Key Vault, HashCorp Vault or AWS Secrets Manager.

You would call out to these vaults to get secrets on demand.

Your deployment tool might have a feature for sensitive varibles (i.e. they shouldn't be retrievable or viewable), but you can call out to a general valut to get secrets, as vaults offer some additional features that make it easier to do the right thing with secrets. There's usually an API to access the secrets and you can do it both during a deployment and at runtime (though there may be service limits).

To sum it all up...

  1. The common strategy for secrets is to use secure vaults - you don't want them in config files or in source control
  2. Each vault will have best practices for access, so when you pick a solution follow their guidance - you can normally lock access by more than authorization (for example, IP restrictions)
  3. One of the key patterns on top of secrets vaults is to rotate secrets frequently (and automatically)

This is like a micro-topic all of its own as you can increase your security by locking things down, applying least privilege, and monitoring access to secrets to spot suspicious activity. I hope this helps as an introduction.

Fenton
  • 323
  • 1
  • 2
  • 9
  • Thanks, I haven't heard of vaults until now. Something that has been mentioned to me in the past is using environment variables. However I'm not sure how these can be set up since even a .env needs to be tracked in source control. – Ewan May 31 '23 at 18:12
  • My take on "best practice" for .env files is that you don't commit them to source control - only an env.template that doens't contain secrets. For local development you would copy env.template to an untracked .env file and "fill in the blanks". At deploy time, you would add .env files based on sensitive variables in your deployment ool or from secrets from your secrets vault. Some people commit encypted versions of the .env file, in which case you would still substitute the secrets per-enrivonment. – Fenton Jun 01 '23 at 07:45