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

[Booker Bense < >]

On Tue, Sep 17, 2013 at 4:41 AM, Sam Pointer < " target="_blank"> > wrote:

Encrypted data bags were never intended to do anything else.  Anyone who uses them for anything else is just setting themselves up for future pain and problems.  Anyone who recommends that anyone use them for anything else is being foolish and reckless.

Encrypted databags provide protection against two kinds of access:

I also disagree, especially with your assertion of what and "how many" things EDB is protecting against.

I've certainly been in the situation of sharing a common Chef code-base amongst many groups where secrets needed to be siloed amongst consumers, and kept from the administrators of the source control system too. We shouldn't assume there is one operations group that is the keeper of all of the keys, because in most large organisations that isn't the case.

Well, I guess I didn't do a very good job of explain the concepts of Implicit and Explicit access, because they cover all the cases you list above. 

Explicit access is using your chef client key to access data in the chef data store via the chef API. 

Implicit access is every other kind of access to the data store via code repo's, database backups, root access on the server, etc...  

My argument is not that EDB's cannot implement both kinds of access control, but that they do it in a way that has bad long term consequences[1] and still leaves you with the problem of installing a secret on the machine. All they really do is establish an  SEP 

field[2] around the problem. 

The reason distributing secrets in an automated way is such a hard problem is that encryption cannot create trust, it can only extend it. Ultimately, you have to pick something to trust and then use that trust to install a secret. The reason this is so difficult in the general case is that every organization has different levels of risk acceptance and items of trust.  

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. 

- Booker C. Bense 

[1]- Especially in large organizations that have significant audit trail requirements. 

[2]- http://en.wikipedia.org/wiki/Somebody_Else's_Problem