[chef] Re: Re: Re: Re: Re: Re: Re: encrypted databag question

[Maven User < >]

Awesome - thanks for the reply.

Might I suggest adding this information to the various wiki pages?  I'm sure someone else will fall into this as well.

It really reads that the third argument can either be the contents of the secret OR the path to the secret file.

Maybe I misread the actual method as well as it seemed to do different things depending on if it was passed a path or not.

What we're doing is hiding staging and production passwords (only) and I'll likely put in a fork that makes sure that if the env is NOT prod or stage, then get the passwords (likely from another databag or from the environment definition.

On Sun, Oct 23, 2011 at 11:46 AM, Seth Falcon < "> > wrote:

Hi Maven User,

On Fri, Oct 21, 2011 at 4:01 PM, Maven User < "> > wrote:
> Ok, maybe this is again overkill, but I got it working like this:
>
> secret =
> Chef::EncryptedDataBagItem.load_secret("C:/chef/encrypted_data_bag_secret")
>
> passwords = Chef::EncryptedDataBagItem.load("prod", "passwords",secret)
>
> That works just fine.
>
> Thoughts?  This seems pretty wonky...

The current design is that EncryptedDataBagItem.load takes the
encryption secret itself, not a path to a file.  If an encryption
secret is not specified, one is loaded via
Chef::Config[:encrypted_data_bag_secret].

The thinking was to keep the storage of the secret decoupled from the
function to load/decrypt.  I can see that taking a path instead of the
secret might increase convenience. The downside is it would prevent
one from obtaining the secret in other ways.

The secret is sensitive to trailing new lines and other whitespace.
EncryptedDataBagItem.load_secret is doing two things for you: (1)
calling IO.read(path).strip which takes care of the trailing newline,
and (2) inspecting the specified path and loading data from a URL if
that is what was specified.

So Matthew's suggestion to use IO.read just needed an extra .strip:

  secret = IO.read("C:/chef/secret").strip

>>> On Fri, Oct 21, 2011 at 5:36 PM, Maven User < "> >
>>> wrote:
>>>>
>>>> Well, that worked, but I'm not sure I'm really jazzed by that solution.
>>>>
>>>> I was able to update my client.rb file to point to the exact file the
>>>> secret was in and it worked.
>>>>
>>>> But, what if different cookbooks have different secret files?

I can imagine wanting to use more than one encrypted data bag item
each with its own secret on the same node. To achieve that with the
current code you will need to use two steps to load as you've done.

I think it would be better to keep cookbooks decoupled from secrets. A
recipe might require one or more encrypted data bag items, but ideally
the secret used is data driven so that dev, preprod, and prod can all
use the same cookbook with different shared secrets.

I'd be interested to hear more details on how you and others are using
encrypted data bag items with a focus on what the encryption is
protecting against.

+ seth

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