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


Chronological Thread 
  • From: AJ Christensen < >
  • To: chef < >
  • Subject: [chef] Re: Re: Handling of encrypted data bag keys
  • Date: Fri, 12 Apr 2013 10:43:38 +1200

We've implemented this at some clients with CloudFormation, IAM
host-keys generated on-demand for each instance, and users/groups for
those keys to access private buckets. Some of the instances can write
to a backup bucket like data-basen.

I have all kinds of fun generating and distributing bits like PKI,
dbag keys, blah blah.

Cheers,

--AJ

On 12 April 2013 06:01, John Martinez 
< >
 wrote:
> Right, and that URI could be an S3 URI protected via a bucket policy.
>
> EBS sounds interesting, but doesn't scale when you've got lots of nodes 
> autoscaling all over the place.
>
>
> On Apr 11, 2013, at 10:54 AM, John E. Vincent (lusis) 
> < >
>  wrote:
>
>> 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.

§