[chef] Re: Re: Re: Re: Re: Re: Re: Encrypted Databags are a Code Smell

[Chris McClimans < >]

Here's some of the early work I did that I suspect chef-vault is based on.

https://gist.github.com/hh/4949041

It may give a simpler view into what's going on underneath.

#1 create a symmetric key that is never saved to disk for use with an EDB

#2 encrypt that symmetric key to the public_key of each node (client) that needs access ( I distribute using a unencrypted data bag for that)

#3 EDB the contents you want known only to those nodes with the symmetric key

#4 throw away the symmetric key

Nodes/Clients search for the data bags from #2 that contain an entry for themselves, decrypt the symmetric key, and open the EDB.

It would be cleaner if we could encrypt directly to all the nodes (clients) at once using some type of PKI.

It's very likely possible, but I haven't enough time on it.

On Tue, Sep 17, 2013 at 10:27 PM, Seth Falcon < " target="_blank"> > wrote:

"> writes:
> Chef already has a item of trust in the key pair each client must have to
> use the system. Rather than creating a whole new ecosystem to manage the
> ACL's and keys of EDB's ( which is what Chef Vault attempts), it seems to
> me to make more sense to try and build something on the existing trust
> item. You already have a process for installing the chef key pair
> client.

I'm confused. Isn't that what Chef Vault is doing? It uses the existing
key pairs in the Chef system to provide access to a shared secret by
encrypting the secret for each public key that needs access to it.

+ seth

--
Seth Falcon | Development Lead | Opscode | @sfalcon