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) <lusis.org+ "> > 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.