Answers: <p>Take a look at <a href="https://pkhub.io" rel="nofollow noreferrer">https://pkhub.io</a> its a cloud secrets manager that's easy to setup and use, see <a href="https://pkhub.io/usecases/environments" rel="nofollow noreferrer">https://pkhub.io/usecases/environments</a>, for a python example.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-08-14T10:54:53.260Z
Answers: 2019-08-14T10:54:53.260Z
Answers: gerritjvv
Answers: <p>We use Chef Vault at my company.  Here's a quick tutorial
  <a href="https://www.youtube.com/watch?v=_hjZpGypu2E" rel="nofollow noreferrer" title="How to Create Chef-Vault">How to Create Chef-Vault</a></p>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-25T03:42:09.187Z
Answers: 2018-03-25T03:42:09.187Z
Answers: daeda
Answers: <h1>Short answer</h1>
  
  <p>Ideally, you should store secrets as environment variables, and retrieve them from a secrets management system like Hashicorp's Vault or AWS Parameter store.</p>
  
  <h1>Long answer</h1>
  
  <p>I saw your questions out of turn, and kinda touched on this in your <a href="https://devops.stackexchange.com/a/3665/6578">other question</a>:</p>
  
  <blockquote>
    <p>Again, there are many perfectly valid options for handling secrets: Chef vault, 1password, environment variables injected by your build instances, home-grown solution using encrypted files stored on object storage, etc....</p>
  </blockquote>
  
  <p>It really depends on how you run and deploy your apps. I worked at a company that used Amazon Beanstalk for production, and they shipped all their secrets and configs as a 'secrets.conf' file that was created by the Jenkins build server, and shipped with the app when it deployed. The problem there was that it was unruly to manage the same secrets across multiple jobs in Jenkins. So, I came in and moved them towards using Chef to create the file instead, and Chef pulled the file from Hashicorp Vault.</p>
  
  <p>At my current company, they are heavy users of GitLab with it's built-in CI/CD build system. Because the the apps are all Docker instances running in Kubernetes, all secrets are actually set as environment variables set during the deployment. The build server gets those from 'secret variables' that is set from the GitLab UI.</p>
  
  <p>These fit the business need at the time, and that's what really matters at the end of the day. However, you if want to be proper, you should store secrets as environment variables because you specifically mention micro services. It is highly recommend that you follow the 12 Factor App approach to configs: <a href="https://12factor.net/config" rel="nofollow noreferrer">https://12factor.net/config</a></p>
  
  <blockquote>
    <p>The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.</p>
  </blockquote>
  
  <p>So you'll definitely want to leverage environment variables. How you <em>set</em> those environment variables could be your Configuration Management system (Ex: Chef), or your build server when it does the deploy, or your apps could be coded to pull directly from your secret storage and set the variables internally.</p>
  
  <p>For actual place where the secrets live (where they are retrieved <em>from</em>), you have a few options. But the 2 you mentioned in your comment would be really great ones to use: Hashicorp's Vault and AWS Parameter store. Others would be Chef Vault, home-grown solution using encrypted files stored on object storage, 1password, etc.... Ideally, you'd want something that can be programmatically access from your build pipeline or apps.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-05T06:15:40.530Z
Answers: Do you also have experience with envy distribution systems that when failures occur, the variables are reverted to the last good set of variables?
Answers: Moritz
Answers: CC BY-SA 3.0
Answers: 2018-04-05T11:18:02.610Z
Answers: Also AWS just added it's own [Secret Manager](https://aws.amazon.com/blogs/aws/aws-secrets-manager-store-distribute-and-rotate-credentials-securely/)
Answers: Levi
Answers: CC BY-SA 3.0
Answers: 2018-04-05T15:03:03.663Z
Answers: @Moritz I don't have any experience with a variable manager. That seems like the logical evolution of "everything is an env variable". Sounds good.
Answers: BoomShadow
Answers: CC BY-SA 3.0
Answers: 2018-03-19T15:12:31.480Z
Answers: 2018-03-19T15:24:52.840Z
Answers: 2018-03-19T15:24:52.840Z
Answers: BoomShadow
Body: <p>The context of the question is <a href="https://devops.stackexchange.com/questions/3658/secrets-management">Secrets management</a>.</p>
  
  <p>How do you manage storing and retrieving secrets for your micro service which is in production?</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-03-18T15:58:52.707Z
Comments: What did you try?
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2018-03-19T08:13:27.037Z
Comments: @030, I've tried out Hashicorp's Vault and recently tried AWS Parameter store.
Comments: Zvika Nadav
Tags: <amazon-web-services><security><microservices><github><encryption>
Title: When your micro service in production needs a secret, where is the secret stored and retrieved from?
UserDisplayName: Zvika Nadav
ThreadText: # When your micro service in production needs a secret, where is the secret stored and retrieved from?
  
  (Asked by: username_0 on 2018-03-18)
  
  The context of the question is [Secrets management](https://devops.stackexchange.com/questions/3658/secrets-management).
  
  How do you manage storing and retrieving secrets for your micro service which is in production?
  
  **Tags:** amazon-web-services, security, microservices, github, encryption
  
  > **Comments:**
  > **username_1**: What did you try?  
  > **username_0**: @username_1, I've tried out Hashicorp's Vault and recently tried AWS Parameter store.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_4 on 2018-03-19. Score: 5 | Accepted answer
  
  # Short answer
  
  Ideally, you should store secrets as environment variables, and retrieve them from a secrets management system like Hashicorp's Vault or AWS Parameter store.
  
  # Long answer
  
  I saw your questions out of turn, and kinda touched on this in your [other question](https://devops.stackexchange.com/a/3665/6578):
  
  > Again, there are many perfectly valid options for handling secrets: Chef vault, 1password, environment variables injected by your build instances, home-grown solution using encrypted files stored on object storage, etc....
  
  It really depends on how you run and deploy your apps. I worked at a company that used Amazon Beanstalk for production, and they shipped all their secrets and configs as a 'secrets.conf' file that was created by the Jenkins build server, and shipped with the app when it deployed. The problem there was that it was unruly to manage the same secrets across multiple jobs in Jenkins. So, I came in and moved them towards using Chef to create the file instead, and Chef pulled the file from Hashicorp Vault.
  
  At my current company, they are heavy users of GitLab with it's built-in CI/CD build system. Because the the apps are all Docker instances running in Kubernetes, all secrets are actually set as environment variables set during the deployment. The build server gets those from 'secret variables' that is set from the GitLab UI.
  
  These fit the business need at the time, and that's what really matters at the end of the day. However, you if want to be proper, you should store secrets as environment variables because you specifically mention micro services. It is highly recommend that you follow the 12 Factor App approach to configs: <https://12factor.net/config>
  
  > The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.
  
  So you'll definitely want to leverage environment variables. How you *set* those environment variables could be your Configuration Management system (Ex: Chef), or your build server when it does the deploy, or your apps could be coded to pull directly from your secret storage and set the variables internally.
  
  For actual place where the secrets live (where they are retrieved *from*), you have a few options. But the 2 you mentioned in your comment would be really great ones to use: Hashicorp's Vault and AWS Parameter store. Others would be Chef Vault, home-grown solution using encrypted files stored on object storage, 1password, etc.... Ideally, you'd want something that can be programmatically access from your build pipeline or apps.
  
  > **Comments:**
  > **username_5**: Do you also have experience with envy distribution systems that when failures occur, the variables are reverted to the last good set of variables?  
  > **username_6**: Also AWS just added it's own [Secret Manager](https://aws.amazon.com/blogs/aws/aws-secrets-manager-store-distribute-and-rotate-credentials-securely/)  
  > **username_4**: @username_5 I don't have any experience with a variable manager. That seems like the logical evolution of "everything is an env variable". Sounds good.  
  
  ---
  
  ### Answer by username_2 on 2019-08-14. Score: 0
  
  Take a look at <https://pkhub.io> its a cloud secrets manager that's easy to setup and use, see <https://pkhub.io/usecases/environments>, for a python example.
  
  
  ---
  
  ### Answer by username_3 on 2018-03-25. Score: 0
  
  We use Chef Vault at my company. Here's a quick tutorial
  [How to Create Chef-Vault](https://www.youtube.com/watch?v=_hjZpGypu2E "How to Create Chef-Vault")
  
  
  ---
  
  