[chef] Re: Re: Re: Re: sensitive data best practices

["Nygard, Michael" < >]

On Sep 9, 2010, at 12:03 AM, "Adam Jacob" 
<
 >
 wrote:

> On Wed, Sep 8, 2010 at 1:05 PM, Jesse Nelson 
> <
 >
>  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
> http://github.com/wesabe/grendel 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: 
>