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

[Booker Bense < >]

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

" target="_blank"> 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.

If I'm reading the documentation correctly, Chef Vault is using public keys to manage access 

to a shared secret for an EDB. If you are going to use EDB's in their current state, this 

is probably the most reasonable approach possible. 

But why use an EDB at all? Why not just encrypt the item with the scheme you are using

to encrypt the access to the item? These are largely rhetorical questions. I completely understand

why chef vault is built the way it is.

We ought to be asking ourselves why Chef Vault is required at all. Implementing ACL's and access control on the client side of a protocol ought to be ringing alarm bells. 

Here's a simple example: 

If I do not rotate keys after every ACL change, then I have only made ACL changes for those clients that play nice. Bad clients

that stash the secret can still access the data items.  

I think the interface to knife that Chef Vault provides covers most of my objections to EDB's. However, before we declare victory and say the problem is solved we should think a bit about the larger problem. I realize this whole area is probably sensitive as ACL's are a "pro feature" of Enterprise Chef. 

- Booker C. Bense