Answers: <p>This question ties in heavily with your <a href="https://devops.stackexchange.com/q/3659/6578">other question</a> with where the secrets are set and where they retrieved from.</p>
  
  <p>I assume your question is asking about 'canary deployments' where you change the config for only a small portion of your apps, to test things out before deploying everywhere.</p>
  
  <p>If you follow the best practice of using the <a href="https://12factor.net/config" rel="nofollow noreferrer">12 Factor app's recommendation</a> of 'environment variables', then changing secrets becomes very easy. At the very worst, you could log into the production server, update the ENV VAR, and then restart your app manually. In Kubernetes, this is even easier, as you can edit the ENV variables from the UI, and then restart the pod.</p>
  
  <p>However, you don't want to be doing that manual process if you can avoid it. If your Configuration Management tool sets the ENV VAR, then you can tell it to update a specific group of servers only. If your build server injects the ENV vars, and it supports canary deployments, then you can easily just do a canary deployment like normal.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-19T18:18:10.567Z
Answers: I'm guessing that by "secret that half of your production applications use right now", OP is referring to something like a password that over half (arbitrary number) of his/her production env is using. Either way, your recommendation of environment variables still applies, and in my opinion is a great approach :)
Answers: Preston Martin
Answers: CC BY-SA 3.0
Answers: 2018-03-19T15:21:19.050Z
Answers: 2018-03-19T19:10:10.760Z
Answers: 2018-03-19T19:10:10.760Z
Answers: BoomShadow
Answers: <p>i wouldn't 'change' the secret at least in the short term but roll out a second secret with the same permission set as the original and roll that out through your configuration management or secrets management.
  ideally following @boomshadow 's answer.
  once the new credential is fully rolled out invalidate the old one/s
  repeat as necessary.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-22T06:31:11.413Z
Answers: 2018-03-22T06:31:11.413Z
Answers: Graeme
Body: <p>The context of the question is <a href="https://devops.stackexchange.com/questions/3658/secrets-management">Secrets management</a>.</p>
  
  <p>As the title says, how do you change a secret that half of your production applications use right now? </p>
  
Comments: CC BY-SA 3.0
Comments: 2018-03-18T15:59:31.140Z
Comments: What did you try?
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2018-03-19T08:13:33.133Z
Comments: @030, I've tried out Hashicorp's Vault and recently tried AWS Parameter store.
Comments: Zvika Nadav
Comments: CC BY-SA 3.0
Comments: 2018-03-19T15:16:24.317Z
Comments: Could you clarify the question of what you mean by 'half of your production applications use right now' ? Are you looking for a way to update only half of your production apps and leave the others as they are, or are you saying you have configs in production that don't match each other and you would like to force a consistence usage of secrets across all of the apps?
Comments: BoomShadow
Tags: <amazon-web-services><security><microservices><github><encryption>
Title: How do you change a secret that half of your production applications use right now?
UserDisplayName: Zvika Nadav
ThreadText: # How do you change a secret that half of your production applications use right now?
  
  (Asked by: username_0 on 2018-03-18)
  
  The context of the question is [Secrets management](https://devops.stackexchange.com/questions/3658/secrets-management).
  
  As the title says, how do you change a secret that half of your production applications use right now?
  
  **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.  
  > **username_2**: Could you clarify the question of what you mean by 'half of your production applications use right now' ? Are you looking for a way to update only half of your production apps and leave the others as they are, or are you saying you have configs in production that don't match each other and you would like to force a consistence usage of secrets across all of the apps?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2018-03-19. Score: 2
  
  This question ties in heavily with your [other question](https://devops.stackexchange.com/q/3659/6578) with where the secrets are set and where they retrieved from.
  
  I assume your question is asking about 'canary deployments' where you change the config for only a small portion of your apps, to test things out before deploying everywhere.
  
  If you follow the best practice of using the [12 Factor app's recommendation](https://12factor.net/config) of 'environment variables', then changing secrets becomes very easy. At the very worst, you could log into the production server, update the ENV VAR, and then restart your app manually. In Kubernetes, this is even easier, as you can edit the ENV variables from the UI, and then restart the pod.
  
  However, you don't want to be doing that manual process if you can avoid it. If your Configuration Management tool sets the ENV VAR, then you can tell it to update a specific group of servers only. If your build server injects the ENV vars, and it supports canary deployments, then you can easily just do a canary deployment like normal.
  
  > **Comments:**
  > **username_3**: I'm guessing that by "secret that half of your production applications use right now", OP is referring to something like a password that over half (arbitrary number) of his/her production env is using. Either way, your recommendation of environment variables still applies, and in my opinion is a great approach :)  
  
  ---
  
  ### Answer by username_4 on 2018-03-22. Score: 0
  
  i wouldn't 'change' the secret at least in the short term but roll out a second secret with the same permission set as the original and roll that out through your configuration management or secrets management.
  ideally following @username_2 's answer.
  once the new credential is fully rolled out invalidate the old one/s
  repeat as necessary.
  
  
  ---
  
  