<p>The current practice for this is to use a secret vault. There are flavours of this, such as <a href="https://learn.microsoft.com/en-us/azure/key-vault/secrets/about-secrets" rel="nofollow noreferrer">Azure Key Vault</a>, <a href="https://www.vaultproject.io/" rel="nofollow noreferrer">HashCorp Vault</a> or <a href="https://aws.amazon.com/secrets-manager/" rel="nofollow noreferrer">AWS Secrets Manager</a>.</p>
<p>You would call out to these vaults to get secrets on demand.</p>
<p>Your deployment tool might have a feature for <a href="https://octopus.com/docs/projects/variables/sensitive-variables" rel="nofollow noreferrer">sensitive varibles</a> (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 <em>do the right thing</em> 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).</p>
<p>To sum it all up...</p>
<ol>
<li>The common strategy for secrets is to use secure vaults - you don't want them in config files or in source control</li>
<li>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)</li>
<li>One of the key patterns on top of secrets vaults is to rotate secrets frequently (and automatically)</li>
</ol>
<p>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.</p>

CC BY-SA 4.0
2023-05-31T18:12:15.207Z
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
CC BY-SA 4.0
2023-06-01T07:45:11.247Z
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
CC BY-SA 4.0
2023-05-31T10:53:15.297Z
2023-05-31T10:53:15.297Z
Fenton
<p>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.</p>
<p>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?</p>
<p>Specifically, I would like to understand:</p>
<ol>
<li>What are the common strategies or tools used to store and manage user secrets securely outside of source control?</li>
<li>How can these secrets be securely accessed by the applications during deployment or runtime?</li>
<li>Are there any recommended techniques or patterns to automate the process of secret management and deployment while minimizing the risk of exposing sensitive information?</li>
</ol>
<p>Any guidance or insights on the best practices, tools, and techniques for handling user secrets in a deployment scenario would be greatly appreciated.</p>

<security>
How do you add user secrets to a deployment without having them to source control?
Ewan
# How do you add user secrets to a deployment without having them to source control?

(Asked by: username_0 on 2023-05-30)

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.

**Tags:** security


---

## 1 answers

### Answer by username_1 on 2023-05-31. Score: 0 | Accepted answer

The current practice for this is to use a secret vault. There are flavours of this, such as [Azure Key Vault](https://learn.microsoft.com/en-us/azure/key-vault/secrets/about-secrets), [HashCorp Vault](https://www.vaultproject.io/) or [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/).

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

Your deployment tool might have a feature for [sensitive varibles](https://octopus.com/docs/projects/variables/sensitive-variables) (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.

> **Comments:**
> **username_0**: 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.  
> **username_1**: 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.  

---

