3 ms·

Secrets or credential management is hard, but the first step is to centralise. Many folk use Vault. There's also Knox, KeyWhiz and I forget some others. I've be

Secrets or credential management is hard, but the first step is to centralise. Many folk use Vault. There's also Knox, KeyWhiz and I forget some others. I've been a secrets-management product team (CredHub) for several months now. We've looked at different ways of shuttling secrets but really, it's going to be specific to the context. For example, one job our software does is to hand credentials to a trusted BOSH director during deployments. That's basically done at this point and works very nicely from an operator perspective. But then when we look at handing secrets to applications, or getting secrets to CI, it's a bit trickier. We use Concourse a lot and for Concourse the next major track of work centres entirely around creating a secrets-management layer that backs onto secret-management systems. Disclosure: At the moment I work on CredHub on behalf of Pivotal.

eropple 10y ago
Not applicable for y'all, but for our AWS people, I'll cape up for Credstash[1] (or its moral equivalent, Sneaker[2], but I prefer the use of a Dynamo table to S3 for this). Uses IAM to ensure secret access and offers revisioning. Plus it's super easy to work with. My normal stack, using my own Auster[3] for orchestration, uses an offline, file-based secrets store (usually an encrypted USB key in production) for stuff like database root passwords that don't need to be online, then push database passwords into Credstash with encryption contexts (the KMS thing that makes IAM effective for this). My Chef cookbooks happily slurp in credstashed secrets via rcredstash, now that the PR to make it work with parameterized KMS keys has hit, and provisioning is very straightforward. (There are a lot of proper nouns in this paragraph, but the nice thing is that each component handles its own business and so there aren't many vertical concerns.) CI secret access isn't a thing in the systems I develop (unit tests don't need them, integration tests get a spun-up environment that provisions its own secrets), but you could provide access with a bog-standard token machine. [1] https://github.com/fugue/credstash https://github.com/fugue/credstash [2] https://github.com/codahale/sneaker https://github.com/codahale/sneaker [3] https://github.com/eropple/auster https://github.com/eropple/auster
dogecoinbase 10y ago
Secrets or credential management is hard, but the first step is to centralise. Ah yes, the "all eggs, one basket" approach to secret management. This is the correct approach, if you are trying to sell a platform -- gets you lock-in, and if you fail to keep secrets secure, you were going to blow up anyways, so the business risk management dictates that you should shoot for the moon and risk your client's data in the hopes of getting traction.
- jacques_chester 10y ago
  That's definitely one way of looking at it. Another view is that: 1. You can't invest in heavily defending scattered resources. 2. Individual teams are not all experts in secret management. Pivotal started CredHub (it's now in the Cloud Foundry Incubation process) partly because of client requests and partly because of the problems we and our fellow Cloud Foundry Foundation members have encountered. There are literally thousands of secrets and credentials scattered across dozens of teams, including hundreds of high-risk operational secrets. We have had multiple unintentional leakages, usually git. It's so easy that we now have tools to watch commits and checkouts for secret-like patterns. The same tools constantly comb our repositories for possible secrets as well. Development teams should not need to care. Operators should not need to have to hand-manage thousands of secrets. There should be a safe, sane, central, highly assured place or places to keep your secrets.

eropple 10y ago

Not applicable for y'all, but for our AWS people, I'll cape up for Credstash[1] (or its moral equivalent, Sneaker[2], but I prefer the use of a Dynamo table to S3 for this). Uses IAM to ensure secret access and offers revisioning. Plus it's super easy to work with. My normal stack, using my own Auster[3] for orchestration, uses an offline, file-based secrets store (usually an encrypted USB key in production) for stuff like database root passwords that don't need to be online, then push database passwords into Credstash with encryption contexts (the KMS thing that makes IAM effective for this). My Chef cookbooks happily slurp in credstashed secrets via rcredstash, now that the PR to make it work with parameterized KMS keys has hit, and provisioning is very straightforward. (There are a lot of proper nouns in this paragraph, but the nice thing is that each component handles its own business and so there aren't many vertical concerns.) CI secret access isn't a thing in the systems I develop (unit tests don't need them, integration tests get a spun-up environment that provisions its own secrets), but you could provide access with a bog-standard token machine. [1] https://github.com/fugue/credstash https://github.com/fugue/credstash [2] https://github.com/codahale/sneaker https://github.com/codahale/sneaker [3] https://github.com/eropple/auster https://github.com/eropple/auster

dogecoinbase 10y ago

Secrets or credential management is hard, but the first step is to centralise. Ah yes, the "all eggs, one basket" approach to secret management. This is the correct approach, if you are trying to sell a platform -- gets you lock-in, and if you fail to keep secrets secure, you were going to blow up anyways, so the business risk management dictates that you should shoot for the moon and risk your client's data in the hopes of getting traction.

jacques_chester 10y ago
That's definitely one way of looking at it. Another view is that: 1. You can't invest in heavily defending scattered resources. 2. Individual teams are not all experts in secret management. Pivotal started CredHub (it's now in the Cloud Foundry Incubation process) partly because of client requests and partly because of the problems we and our fellow Cloud Foundry Foundation members have encountered. There are literally thousands of secrets and credentials scattered across dozens of teams, including hundreds of high-risk operational secrets. We have had multiple unintentional leakages, usually git. It's so easy that we now have tools to watch commits and checkouts for secret-like patterns. The same tools constantly comb our repositories for possible secrets as well. Development teams should not need to care. Operators should not need to have to hand-manage thousands of secrets. There should be a safe, sane, central, highly assured place or places to keep your secrets.