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

[Daniel DeLeo < >]

-- 

Daniel DeLeo

On Monday, September 16, 2013 at 12:49 PM, Brad Knowles wrote:

On Sep 16, 2013, at 1:54 PM, Booker Bense < "> > wrote:

http://fredthemagicwonderdog.blogspot.com/2013/09/chef-encrypted-data-bags-are-code-smell.html

The more I think about it, the more I think encrypted data bags aren't the solution.

The problem that was intended to be solved by encrypted data bags is where you share the Chef Server infrastructure with one or more other parties, and where you do not trust that infrastructure. Therefore, you encrypt your data bag content before uploading it to the Chef Server, and on the other end you decrypt it after you download the data bag content from the Chef Server. This is done with symmetric encryption keys.

In other words, they're solving the problem of not trusting a Hosted Chef environment.

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.

I'm not convinced that Chef Vault is anything of an improvement in this space, except perhaps for the issue of how to distribute a shared symmetric encryption key. I'm still trying to figure out how I feel about that.

Meanwhile, if we could completely eliminate the shared symmetric encryption key and use asymmetric public key cryptography instead, I think that would go a long ways towards solving at least some of the problems.

I know that Chef Vault tries to do this to a degree, but I am not convinced that they have covered all or even most of the holes that need to be addressed.

--

Brad Knowles < "> >

I disagree. By controlling which machines you distribute which secrets to, you can limit exposure of secrets if a particular machine is compromised. We've certainly found this useful even for infrastructure we manage with a Chef server completely under our control.

That said, more elegant and flexible solutions are possible, and at Opscode we're not opposed to anyone developing them as a standalone project or as a feature patch to Chef.

-- 

Daniel DeLeo