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

["John E. Vincent (lusis)" < >]

I tend to agree with Brad here about the proper role of encrypted databags. Having been somewhat involved with them early on, I figured I'd relink some old blog posts on the subject:

http://lusislog.blogspot.com/2010/12/chef-and-encrypted-data-bags.html

http://lusislog.blogspot.com/2011/01/chef-and-encrypted-data-bags-revisted.html

Really encrypted databags are nothing more than obfuscation. The reality check section on the first link is my perspective. Everyone's shit has more risky attack vectors than just chef databags. Additionally they don't even begin to deal with advanced issues like Authorization or Authentication (though Chef-Vault handles some of that). Your API creds or validation pem are a bigger attack vector than one encrypted value.

With the API creds I can upload a new cookbook or databag that creates a user for me on one of your systems and I'll have access. Then I don't even CARE about the encrypted creds. I'll just find the file on the system where you're writing the decrypted values.

On Mon, Sep 16, 2013 at 3:49 PM, Brad Knowles < " target="_blank"> > 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 < "> >
LinkedIn Profile: <http://tinyurl.com/y8kpxu>