Where to store credentials for devops?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
We have code (in git) together with configuration/deployment/build scripts (fabfile.py, circle.yml, Dockerfile etc) which result in a pretty seamless automatic build/deploy process. The one part which is not seamless is where to store credentials of various kinds. These are things like ssh keys, code signing certificates, aws access keys, ssl certificates... Currently the process is to copy the needed keys/certs from a flash drive and then (eg) run fabric.
It seems like storing credentials like this in git (alongside code) is not the best place, but what is the best place? Is there a recommended best practice for where to store information like this for devops? Is there a reference that discusses different options with their pros and cons?
ssl-certificate credentials ssh-keys devops
add a comment |
We have code (in git) together with configuration/deployment/build scripts (fabfile.py, circle.yml, Dockerfile etc) which result in a pretty seamless automatic build/deploy process. The one part which is not seamless is where to store credentials of various kinds. These are things like ssh keys, code signing certificates, aws access keys, ssl certificates... Currently the process is to copy the needed keys/certs from a flash drive and then (eg) run fabric.
It seems like storing credentials like this in git (alongside code) is not the best place, but what is the best place? Is there a recommended best practice for where to store information like this for devops? Is there a reference that discusses different options with their pros and cons?
ssl-certificate credentials ssh-keys devops
add a comment |
We have code (in git) together with configuration/deployment/build scripts (fabfile.py, circle.yml, Dockerfile etc) which result in a pretty seamless automatic build/deploy process. The one part which is not seamless is where to store credentials of various kinds. These are things like ssh keys, code signing certificates, aws access keys, ssl certificates... Currently the process is to copy the needed keys/certs from a flash drive and then (eg) run fabric.
It seems like storing credentials like this in git (alongside code) is not the best place, but what is the best place? Is there a recommended best practice for where to store information like this for devops? Is there a reference that discusses different options with their pros and cons?
ssl-certificate credentials ssh-keys devops
We have code (in git) together with configuration/deployment/build scripts (fabfile.py, circle.yml, Dockerfile etc) which result in a pretty seamless automatic build/deploy process. The one part which is not seamless is where to store credentials of various kinds. These are things like ssh keys, code signing certificates, aws access keys, ssl certificates... Currently the process is to copy the needed keys/certs from a flash drive and then (eg) run fabric.
It seems like storing credentials like this in git (alongside code) is not the best place, but what is the best place? Is there a recommended best practice for where to store information like this for devops? Is there a reference that discusses different options with their pros and cons?
ssl-certificate credentials ssh-keys devops
ssl-certificate credentials ssh-keys devops
asked Oct 29 '16 at 1:25
Alex IAlex I
13.2k452109
13.2k452109
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
The problem of secrets management is still something that hasn't exactly been "solved" by the use of any tool.
You can use any of the various Secrets Management Tools (each offers different types of benefits / integrations).
I personally prefer Hashicorp Vault. Cyberark is another good one.
The way you use these tools in your solution however, there are some common use patterns.
1) You can store your secrets in code in your SCM IF they are encrypted... But this still results in the same problem, you still need to deliver a secret securely at deploy time (or have it available at startup) to be able to decrypt the secrets (password, credentials, secrets, certs) that have been deployed. That is where the Secrets Management Tool (such a Vault) comes in. The tool will allow you to securely retrieve your secret for use in decryption of the secrets when it's needed.
2) The other way as mentioned above is. Is to actually store all secrets, certs etc. outside of the SCM in the Secret Management Tool itself and retrieve them at deploy / startup time.
Obviously there are pros and cons to doing things either way. i.e. the first approach reduces complexity as you only manage one or two secrets at any given time. On the other hand, if you store all secrets in a vault, the potential for compromises associated with your entire ecosystem is reduced, as access to a single secret doesn't allow someone access to every other secret.
At the end of the day it all comes down to your use case / the security constructs available and of course the people you are surrounded with. Because at the end of the day, someone, somewhere needs to know a secret...
add a comment |
Yes. There is a recommendation. It is the usage of Cloud Vault. Take a look on some good examples:
https://www.hashicorp.com/blog/vault.html
https://blog.keepersecurity.com/2016/08/16/keeper-for-devops-more-than-just-passwords/
add a comment |
It's a kind of best practice to use a proper Security when it comes to credentials. As it can lead to Web Hack and other potential loss to the company.
Best way to do it to use Kind of Vault.
- https://www.vaultproject.io/
- https://docs.ansible.com/ansible/2.4/vault.html
- AWS KMS
add a comment |
protected by Community♦ Feb 7 '18 at 3:49
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
The problem of secrets management is still something that hasn't exactly been "solved" by the use of any tool.
You can use any of the various Secrets Management Tools (each offers different types of benefits / integrations).
I personally prefer Hashicorp Vault. Cyberark is another good one.
The way you use these tools in your solution however, there are some common use patterns.
1) You can store your secrets in code in your SCM IF they are encrypted... But this still results in the same problem, you still need to deliver a secret securely at deploy time (or have it available at startup) to be able to decrypt the secrets (password, credentials, secrets, certs) that have been deployed. That is where the Secrets Management Tool (such a Vault) comes in. The tool will allow you to securely retrieve your secret for use in decryption of the secrets when it's needed.
2) The other way as mentioned above is. Is to actually store all secrets, certs etc. outside of the SCM in the Secret Management Tool itself and retrieve them at deploy / startup time.
Obviously there are pros and cons to doing things either way. i.e. the first approach reduces complexity as you only manage one or two secrets at any given time. On the other hand, if you store all secrets in a vault, the potential for compromises associated with your entire ecosystem is reduced, as access to a single secret doesn't allow someone access to every other secret.
At the end of the day it all comes down to your use case / the security constructs available and of course the people you are surrounded with. Because at the end of the day, someone, somewhere needs to know a secret...
add a comment |
The problem of secrets management is still something that hasn't exactly been "solved" by the use of any tool.
You can use any of the various Secrets Management Tools (each offers different types of benefits / integrations).
I personally prefer Hashicorp Vault. Cyberark is another good one.
The way you use these tools in your solution however, there are some common use patterns.
1) You can store your secrets in code in your SCM IF they are encrypted... But this still results in the same problem, you still need to deliver a secret securely at deploy time (or have it available at startup) to be able to decrypt the secrets (password, credentials, secrets, certs) that have been deployed. That is where the Secrets Management Tool (such a Vault) comes in. The tool will allow you to securely retrieve your secret for use in decryption of the secrets when it's needed.
2) The other way as mentioned above is. Is to actually store all secrets, certs etc. outside of the SCM in the Secret Management Tool itself and retrieve them at deploy / startup time.
Obviously there are pros and cons to doing things either way. i.e. the first approach reduces complexity as you only manage one or two secrets at any given time. On the other hand, if you store all secrets in a vault, the potential for compromises associated with your entire ecosystem is reduced, as access to a single secret doesn't allow someone access to every other secret.
At the end of the day it all comes down to your use case / the security constructs available and of course the people you are surrounded with. Because at the end of the day, someone, somewhere needs to know a secret...
add a comment |
The problem of secrets management is still something that hasn't exactly been "solved" by the use of any tool.
You can use any of the various Secrets Management Tools (each offers different types of benefits / integrations).
I personally prefer Hashicorp Vault. Cyberark is another good one.
The way you use these tools in your solution however, there are some common use patterns.
1) You can store your secrets in code in your SCM IF they are encrypted... But this still results in the same problem, you still need to deliver a secret securely at deploy time (or have it available at startup) to be able to decrypt the secrets (password, credentials, secrets, certs) that have been deployed. That is where the Secrets Management Tool (such a Vault) comes in. The tool will allow you to securely retrieve your secret for use in decryption of the secrets when it's needed.
2) The other way as mentioned above is. Is to actually store all secrets, certs etc. outside of the SCM in the Secret Management Tool itself and retrieve them at deploy / startup time.
Obviously there are pros and cons to doing things either way. i.e. the first approach reduces complexity as you only manage one or two secrets at any given time. On the other hand, if you store all secrets in a vault, the potential for compromises associated with your entire ecosystem is reduced, as access to a single secret doesn't allow someone access to every other secret.
At the end of the day it all comes down to your use case / the security constructs available and of course the people you are surrounded with. Because at the end of the day, someone, somewhere needs to know a secret...
The problem of secrets management is still something that hasn't exactly been "solved" by the use of any tool.
You can use any of the various Secrets Management Tools (each offers different types of benefits / integrations).
I personally prefer Hashicorp Vault. Cyberark is another good one.
The way you use these tools in your solution however, there are some common use patterns.
1) You can store your secrets in code in your SCM IF they are encrypted... But this still results in the same problem, you still need to deliver a secret securely at deploy time (or have it available at startup) to be able to decrypt the secrets (password, credentials, secrets, certs) that have been deployed. That is where the Secrets Management Tool (such a Vault) comes in. The tool will allow you to securely retrieve your secret for use in decryption of the secrets when it's needed.
2) The other way as mentioned above is. Is to actually store all secrets, certs etc. outside of the SCM in the Secret Management Tool itself and retrieve them at deploy / startup time.
Obviously there are pros and cons to doing things either way. i.e. the first approach reduces complexity as you only manage one or two secrets at any given time. On the other hand, if you store all secrets in a vault, the potential for compromises associated with your entire ecosystem is reduced, as access to a single secret doesn't allow someone access to every other secret.
At the end of the day it all comes down to your use case / the security constructs available and of course the people you are surrounded with. Because at the end of the day, someone, somewhere needs to know a secret...
answered Feb 6 '18 at 5:26
JesseJesse
8541917
8541917
add a comment |
add a comment |
Yes. There is a recommendation. It is the usage of Cloud Vault. Take a look on some good examples:
https://www.hashicorp.com/blog/vault.html
https://blog.keepersecurity.com/2016/08/16/keeper-for-devops-more-than-just-passwords/
add a comment |
Yes. There is a recommendation. It is the usage of Cloud Vault. Take a look on some good examples:
https://www.hashicorp.com/blog/vault.html
https://blog.keepersecurity.com/2016/08/16/keeper-for-devops-more-than-just-passwords/
add a comment |
Yes. There is a recommendation. It is the usage of Cloud Vault. Take a look on some good examples:
https://www.hashicorp.com/blog/vault.html
https://blog.keepersecurity.com/2016/08/16/keeper-for-devops-more-than-just-passwords/
Yes. There is a recommendation. It is the usage of Cloud Vault. Take a look on some good examples:
https://www.hashicorp.com/blog/vault.html
https://blog.keepersecurity.com/2016/08/16/keeper-for-devops-more-than-just-passwords/
answered Oct 29 '16 at 3:42
Anderson OkiAnderson Oki
448415
448415
add a comment |
add a comment |
It's a kind of best practice to use a proper Security when it comes to credentials. As it can lead to Web Hack and other potential loss to the company.
Best way to do it to use Kind of Vault.
- https://www.vaultproject.io/
- https://docs.ansible.com/ansible/2.4/vault.html
- AWS KMS
add a comment |
It's a kind of best practice to use a proper Security when it comes to credentials. As it can lead to Web Hack and other potential loss to the company.
Best way to do it to use Kind of Vault.
- https://www.vaultproject.io/
- https://docs.ansible.com/ansible/2.4/vault.html
- AWS KMS
add a comment |
It's a kind of best practice to use a proper Security when it comes to credentials. As it can lead to Web Hack and other potential loss to the company.
Best way to do it to use Kind of Vault.
- https://www.vaultproject.io/
- https://docs.ansible.com/ansible/2.4/vault.html
- AWS KMS
It's a kind of best practice to use a proper Security when it comes to credentials. As it can lead to Web Hack and other potential loss to the company.
Best way to do it to use Kind of Vault.
- https://www.vaultproject.io/
- https://docs.ansible.com/ansible/2.4/vault.html
- AWS KMS
answered Nov 23 '18 at 8:27
AnmolNagpalAnmolNagpal
1337
1337
add a comment |
add a comment |
protected by Community♦ Feb 7 '18 at 3:49
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?