How are people sensitive data?
For example ‘passwords’… not just passwords for the nodes but for other
services like mysql that are running.
Anyone doing something they think is awesomely secure?
We've had a couple of different approaches. One is to store secrets
in data bags, another is to store it as node attribute data.
A third alternative would be to encrypt the data yourself, and then
deal with key distribution. You can't avoid this - at some point, if
you want the data to be both available and secure, you'll have to
encrypt it, and you'll have to distribute the keys.
Adam
On Mon, Sep 6, 2010 at 7:57 PM, Andrew Shafer andrew@cloudscaling.com wrote:
How are people sensitive data?
For example 'passwords'... not just passwords for the nodes but for other
services like mysql that are running.
Anyone doing something they think is awesomely secure?
--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com
A "secure" method for storing individual attributes would be slick. Server already has all clients pub keys. It could use to encrypt and clients can unwind on their end. Seems like that shouldn't be too hard to implement, but I am pretty ignorant about the api internals.
This solution would solve not storing cleartext in couch, and over the wire. I suppose it would have to also replace the strings in the cookbook when stored. Access to couch and client keys still fundamentally being an issue.
Personally haven't had to solve this problem yet, but i've been thinking about it a bit for some work on the horizon.
On Sep 8, 2010, at 9:15 AM, Adam Jacob wrote:
We've had a couple of different approaches. One is to store secrets
in data bags, another is to store it as node attribute data.A third alternative would be to encrypt the data yourself, and then
deal with key distribution. You can't avoid this - at some point, if
you want the data to be both available and secure, you'll have to
encrypt it, and you'll have to distribute the keys.Adam
On Mon, Sep 6, 2010 at 7:57 PM, Andrew Shafer andrew@cloudscaling.com wrote:
How are people sensitive data?
For example 'passwords'... not just passwords for the nodes but for other
services like mysql that are running.
Anyone doing something they think is awesomely secure?--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com
On Wed, Sep 8, 2010 at 1:05 PM, Jesse Nelson spheromak@gmail.com wrote:
A "secure" method for storing individual attributes would be slick. Server already has all clients pub keys. It could use to encrypt and clients can unwind on their end. Seems like that shouldn't be too hard to implement, but I am pretty ignorant about the api internals.
This solution would solve not storing cleartext in couch, and over the wire. I suppose it would have to also replace the strings in the cookbook when stored. Access to couch and client keys still fundamentally being an issue.
Personally haven't had to solve this problem yet, but i've been thinking about it a bit for some work on the horizon.
Not sending the cleartext over the wire is solved with SSL, I think.
If the Chef Server is doing the encryption for each client
specifically, that implies a clear-text copy remains on the server.
If you really want it to be end-to-end secure, I think you probably
have to have an external public/private key pair that gets
individually distributed. Something like Grendel
GitHub - wesabe/grendel: Grendel is a RESTful web service which allows for the secure storage of users' documents. is really where you would want to
land. Note they still have a key distribution issue - you pass your
password to grendel to unlock your OpenPGP key, which then can be used
to re-encrypt the data for other linked users.
I think any good answer to this question is going to involve lots of
thinking about the exact use cases. For example, I've built a
password escrow service before specifically for passing the Sarbanes
Oxley audit requirement that developers not have access to production
passwords for financial systems. It stored the actual secret on a
secured machine, and granted access to production systems through
indirection, and updated configuration templates or services on
demand. It worked for the use case, but I don't think it's general
purpose applicable here.
Is the primary use case people storing passwords?
Adam
--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com
On Thu, Sep 9, 2010 at 06:02, Adam Jacob adam@opscode.com wrote:
I think any good answer to this question is going to involve lots of
thinking about the exact use cases. For example, I've built a
password escrow service before specifically for passing the Sarbanes
Oxley audit requirement that developers not have access to production
passwords for financial systems. It stored the actual secret on a
secured machine, and granted access to production systems through
indirection, and updated configuration templates or services on
demand. It worked for the use case, but I don't think it's general
purpose applicable here.Is the primary use case people storing passwords?
I wonder if ACLs might not be a reasonable way of securing this;
be able to have "secure" attributes that you can ACL differently to
normal attributes.
It's obviously not good enough to pass SOX or PCI, but for day to day
use cases like
giving developers access to chef but remove their ability to view
production passwords
it's probably good enough.
-Thom
On Sep 9, 2010, at 12:03 AM, "Adam Jacob" adam@opscode.com wrote:
On Wed, Sep 8, 2010 at 1:05 PM, Jesse Nelson spheromak@gmail.com wrote:
A "secure" method for storing individual attributes would be slick. Server already has all clients pub keys. It could use to encrypt and clients can unwind on their end. Seems like that shouldn't be too hard to implement, but I am pretty ignorant about the api internals.
This solution would solve not storing cleartext in couch, and over the wire. I suppose it would have to also replace the strings in the cookbook when stored. Access to couch and client keys still fundamentally being an issue.
Personally haven't had to solve this problem yet, but i've been thinking about it a bit for some work on the horizon.
Not sending the cleartext over the wire is solved with SSL, I think.
If the Chef Server is doing the encryption for each client
specifically, that implies a clear-text copy remains on the server.If you really want it to be end-to-end secure, I think you probably
have to have an external public/private key pair that gets
individually distributed. Something like Grendel
GitHub - wesabe/grendel: Grendel is a RESTful web service which allows for the secure storage of users' documents. is really where you would want to
land. Note they still have a key distribution issue - you pass your
password to grendel to unlock your OpenPGP key, which then can be used
to re-encrypt the data for other linked users.I think any good answer to this question is going to involve lots of
thinking about the exact use cases. For example, I've built a
password escrow service before specifically for passing the Sarbanes
Oxley audit requirement that developers not have access to production
passwords for financial systems. It stored the actual secret on a
secured machine, and granted access to production systems through
indirection, and updated configuration templates or services on
demand. It worked for the use case, but I don't think it's general
purpose applicable here.Is the primary use case people storing passwords?
I have a similar use case to your financial system. SOX and PCI (at least, local interpretations) both require no dev access to production databases. At the same time, I want all the devs to see the chef-repo and be fluent with cookbooks. Therefore, I can't keep passwords in cookbooks. If I keep them in data bags, I can look it up from the recipe, but I have to modify the recipes because data bag lookups are disjoint from attribute reads.
Even then, it means I can't let the devs log into the chef server. It would be nice if I could, so they could see all the non-sensitive attributes directly.
I have the exact same issue with encryption keys.
Cheers,
-Michael Nygard
Adam
--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com
We're prototyping an approach where senstive environment-specific
attribute values are kept in a top-level role that's specific to the
environment, and its run list is simply a "real" role whose run-list has
all of the cookbooks for that role, and attr values for all
non-sensitive data. Each environment (prod, dev, qa, etc) will have a
small repo that contains only those top-level roles, with actual values
for the sensitive attributes. It does mean we have to load each Chef
server from two different repos (the main repo with all the cookbooks
and roles and the environment-specific repo with just the top-level
roles), though. We'll see how awkward that proves to be.
We're quite interested to see how the new environment feature in Chef
turns out, though!
-Jim
On 09/09/2010 05:44 AM, Nygard, Michael wrote:
On Sep 9, 2010, at 12:03 AM, "Adam Jacob"adam@opscode.com wrote:
On Wed, Sep 8, 2010 at 1:05 PM, Jesse Nelsonspheromak@gmail.com wrote:
A "secure" method for storing individual attributes would be slick. Server already has all clients pub keys. It could use to encrypt and clients can unwind on their end. Seems like that shouldn't be too hard to implement, but I am pretty ignorant about the api internals.
This solution would solve not storing cleartext in couch, and over the wire. I suppose it would have to also replace the strings in the cookbook when stored. Access to couch and client keys still fundamentally being an issue.
Personally haven't had to solve this problem yet, but i've been thinking about it a bit for some work on the horizon.
Not sending the cleartext over the wire is solved with SSL, I think.
If the Chef Server is doing the encryption for each client
specifically, that implies a clear-text copy remains on the server.If you really want it to be end-to-end secure, I think you probably
have to have an external public/private key pair that gets
individually distributed. Something like Grendel
GitHub - wesabe/grendel: Grendel is a RESTful web service which allows for the secure storage of users' documents. is really where you would want to
land. Note they still have a key distribution issue - you pass your
password to grendel to unlock your OpenPGP key, which then can be used
to re-encrypt the data for other linked users.I think any good answer to this question is going to involve lots of
thinking about the exact use cases. For example, I've built a
password escrow service before specifically for passing the Sarbanes
Oxley audit requirement that developers not have access to production
passwords for financial systems. It stored the actual secret on a
secured machine, and granted access to production systems through
indirection, and updated configuration templates or services on
demand. It worked for the use case, but I don't think it's general
purpose applicable here.Is the primary use case people storing passwords?
I have a similar use case to your financial system. SOX and PCI (at least, local interpretations) both require no dev access to production databases. At the same time, I want all the devs to see the chef-repo and be fluent with cookbooks. Therefore, I can't keep passwords in cookbooks. If I keep them in data bags, I can look it up from the recipe, but I have to modify the recipes because data bag lookups are disjoint from attribute reads.
Even then, it means I can't let the devs log into the chef server. It would be nice if I could, so they could see all the non-sensitive attributes directly.
I have the exact same issue with encryption keys.
Cheers,
-Michael NygardAdam
--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com
On 7 September 2010 03:57, Andrew Shafer andrew@cloudscaling.com wrote:
How are people sensitive data?
For example 'passwords'... not just passwords for the nodes but for other
services like mysql that are running.
Anyone doing something they think is awesomely secure?
It's in no way awesomely secure, but I'm keeping information like that
as attributes on the node. It might not make sense in your
environment, but in mine I can safely work on the assumption that if
someone has compromised the Chef server and got access to node
attributes I'm royally screwed far beyond someone logging into the
MySQL server anyway.