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


Chronological Thread 
  • From: Adam Jacob < >
  • To:
  • Subject: [chef] Re: Re: Re: sensitive data best practices
  • Date: Wed, 8 Sep 2010 22:02:57 -0700

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?

Adam

-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: 




Archive powered by MHonArc 2.6.16.

§