We use private S3 buckets for a bunch of stuff, so pulling the databag key
from there isn’t a big stretch.
I just wrote https://github.com/thommay/chef-encrypted-databags (lightly
tested, if it breaks you get to keep both pieces, etc) to do that.
On Thu, Apr 11, 2013 at 6:05 PM, Moser, Kevin Kevin.Moser@nordstrom.comwrote:
We are asking a very similar question ourselves. We are using encrypted
data bags to store passwords and certificates. We ended up writing what we
are calling chef-vault (distributed as a ruby gem, source at
github.com/moserke/chef-vault). It uses the chef client key to encrypt
the shared secret for the host that needs to decrypt it. That host can now
use it’s private key to decrypt the shared secret to then go to the real
data bag and decrypt the password.
This does have minor chicken and egg issue for a boot strap, as you need
the client to run with the validator to get it’s pem so that you can use
the knife plugins in the gem. For us this works ok because we converge the
box into the base role first (which doesn’t need the encrypted values) do
the encryption for that host and then put the host into the application
role that needs the encrypted value.
This approach takes the need out of the client ever needing to “store” or
have local the secret as it’s all stored in data bags and protected by the
clients private key.
From: Thom May <email@example.com<mailto:
Reply-To: "firstname.lastname@example.org:email@example.com" <
Date: Thursday, April 11, 2013 5:13 AM
To: "firstname.lastname@example.org:email@example.com" <
Subject: [chef] Re: Re: Handling of encrypted data bag keys
thanks, but that’s not really the problem I want to solve.
Now, whenever you bootstrap the node on ec2, it will be copied over the
On Thursday, April 11, 2013 at 4:45 PM, Thom May wrote:
how are people handling the distribution of encryption keys for data bags?
It seems unfortunate to have to copy out the encryption key at bootstrap
time, but having it as a cookbook file is daft.
So then I was thinking I’d have the key on a private s3 bucket, which
could then be accessed with signed urls.
But then I thought, if we’re doing that, why bother putting the file on
disk at all? Just download the contents at the start of the chef run, use
it for the duration, and let the key go away when the chef process dies.
Am I missing something?