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

[Jim Hopp < >]

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"<
>  >
>   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: 
> >
> >  
> >