- 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.