[chef] Re: Re: Re: Re: Re: Re: Handling of encrypted data bag keys


Chronological Thread 
  • From: "John E. Vincent (lusis)" < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Handling of encrypted data bag keys
  • Date: Thu, 11 Apr 2013 13:54:10 -0400

I'm assuming everyone is aware that the native encrypted databag stuff
supports pulling the key from a URI so nothing is preventing you from
storing the key on a protected internal host. At previous company, we
just stored it in Noah (RIP) but the idea is the same.

Another approach if you're all EC2 is to use IAM'd credentials to
mount a small EBS volume containing the key as part of a bootstrap
process.

On Thu, Apr 11, 2013 at 1:45 PM, Cassiano Leal 
< >
 wrote:
> Interesting solution. Setting the AWS access_key_id and secret_access_key as
> node attributes doesn't seem right, though. Why go to the trouble of
> encrypting a data bag, if decrypting it is just a matter of reading these
> attributes?
>
> You could use IAM Instance Profiles instead, and have the instance itself
> grab the keys from IAM. These keys are temporary too, so the only way to get
> hold of them is to actually log into the instance.
>
> For an even leaner approach, combine that with the Fog gem instead of
> aws-sdk and just call:
>
> Fog::Storage::AWS.new :use_iam_profile => true
>
> That will take care of the credentials for you, including refreshing the
> keys when they expire.
>
> - cassiano
>
> On Thursday, April 11, 2013 at 14:20, Thom May wrote:
>
> 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.
> -t
>
>
> On Thu, Apr 11, 2013 at 6:05 PM, Moser, Kevin 
> < >
> wrote:
>
> 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.
>
> Kevin
>
> From: Thom May
> < <mailto: >>
> Reply-To: 
> " <mailto: >"
> < <mailto: >>
> Date: Thursday, April 11, 2013 5:13 AM
> To: 
> " <mailto: >"
> < <mailto: >>
> Subject: [chef] Re: Re: Handling of encrypted data bag keys
>
> thanks, but that's not really the problem I want to solve.
>
>
> On Thu, Apr 11, 2013 at 12:49 PM, Sachin Sagar Rai
> < <mailto: >>
>  wrote:
> You can put the following line in knife.rb file
>
>
> encrypted_data_bag_secret "#{home_dir}/.chef/encrypted_data_bag_secret"
>
>
> Now, whenever you bootstrap the node on ec2, it will be copied over the node
> automatically.
>
> -------------------------------------------
> @millisami
> ~ Sachin Sagar Rai
> Ruby on Rails Developer
> http://tfm.com.np
> http://nepalonrails.com<http://nepalonrails.tumblr.com>
> http://funsole.com
> Sent with Sparrow<http://www.sparrowmailapp.com/?sig>
>
>
> On Thursday, April 11, 2013 at 4:45 PM, Thom May wrote:
>
> Hey,
> 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?
> -T
>
>
>
>



Archive powered by MHonArc 2.6.16.

§