Re: Re: Re: Re: Handling of encrypted data bag keys

Chef Infra (archive)
1

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 GitHub - thommay/chef-encrypted-databags: Handle encrypted databags with a key from S3 (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 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 - moserke/chef-vault: Development repository for Opscode's chef-vault cookbook). 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 <thom@clearairturbulence.org<mailto:
thom@clearairturbulence.org>>
Reply-To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <
chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Thursday, April 11, 2013 5:13 AM
To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <
chef@lists.opscode.commailto:chef@lists.opscode.com>
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 <millisami@gmail.com
mailto:millisami@gmail.com> 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.comhttp://nepalonrails.tumblr.com
http://funsole.com
Sent with Sparrowhttp://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

2

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 GitHub - thommay/chef-encrypted-databags: Handle encrypted databags with a key from S3 (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 <Kevin.Moser@nordstrom.com (mailto:Kevin.Moser@nordstrom.com)> 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 - moserke/chef-vault: Development repository for Opscode's chef-vault cookbook (GitHub - moserke/chef-vault: Development repository for Opscode's chef-vault cookbook)). 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 <thom@clearairturbulence.org (mailto:thom@clearairturbulence.org)mailto:thom@clearairturbulence.org>
Reply-To: "chef@lists.opscode.com (mailto:chef@lists.opscode.com)mailto:chef@lists.opscode.com" <chef@lists.opscode.com (mailto:chef@lists.opscode.com)mailto:chef@lists.opscode.com>
Date: Thursday, April 11, 2013 5:13 AM
To: "chef@lists.opscode.com (mailto:chef@lists.opscode.com)mailto:chef@lists.opscode.com" <chef@lists.opscode.com (mailto:chef@lists.opscode.com)mailto:chef@lists.opscode.com>
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 <millisami@gmail.com (mailto:millisami@gmail.com)mailto:millisami@gmail.com> 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.comhttp://nepalonrails.tumblr.com
http://funsole.com
Sent with Sparrowhttp://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

3

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 cassianoleal@gmail.com 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 GitHub - thommay/chef-encrypted-databags: Handle encrypted databags with a key from S3 (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 Kevin.Moser@nordstrom.com
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 - moserke/chef-vault: Development repository for Opscode's chef-vault cookbook). 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
<thom@clearairturbulence.orgmailto:thom@clearairturbulence.org>
Reply-To: "chef@lists.opscode.commailto:chef@lists.opscode.com"
<chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Thursday, April 11, 2013 5:13 AM
To: "chef@lists.opscode.commailto:chef@lists.opscode.com"
<chef@lists.opscode.commailto:chef@lists.opscode.com>
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
<millisami@gmail.commailto:millisami@gmail.com> 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.comhttp://nepalonrails.tumblr.com
http://funsole.com
Sent with Sparrowhttp://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

4

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+chef-list@gmail.com 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 cassianoleal@gmail.com 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 GitHub - thommay/chef-encrypted-databags: Handle encrypted databags with a key from S3 (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 Kevin.Moser@nordstrom.com
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 - moserke/chef-vault: Development repository for Opscode's chef-vault cookbook). 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
<thom@clearairturbulence.orgmailto:thom@clearairturbulence.org>
Reply-To: "chef@lists.opscode.commailto:chef@lists.opscode.com"
<chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Thursday, April 11, 2013 5:13 AM
To: "chef@lists.opscode.commailto:chef@lists.opscode.com"
<chef@lists.opscode.commailto:chef@lists.opscode.com>
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
<millisami@gmail.commailto:millisami@gmail.com> 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.comhttp://nepalonrails.tumblr.com
http://funsole.com
Sent with Sparrowhttp://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

5

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 john@johnmartinez.com 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+chef-list@gmail.com 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 cassianoleal@gmail.com 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 GitHub - thommay/chef-encrypted-databags: Handle encrypted databags with a key from S3 (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 Kevin.Moser@nordstrom.com
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 - moserke/chef-vault: Development repository for Opscode's chef-vault cookbook). 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
<thom@clearairturbulence.orgmailto:thom@clearairturbulence.org>
Reply-To: "chef@lists.opscode.commailto:chef@lists.opscode.com"
<chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Thursday, April 11, 2013 5:13 AM
To: "chef@lists.opscode.commailto:chef@lists.opscode.com"
<chef@lists.opscode.commailto:chef@lists.opscode.com>
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
<millisami@gmail.commailto:millisami@gmail.com> 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.comhttp://nepalonrails.tumblr.com
http://funsole.com
Sent with Sparrowhttp://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

6

Our real problem is that we're not a homogenous EC2 environment, so IAM
doesn't work out so well. S3 is a decent solution that's actually
accessible for all our nodes, but distributing the keys to sign S3 URIs is
a hard problem, too.

On Thu, Apr 11, 2013 at 11:43 PM, AJ Christensen aj@junglist.gen.nz wrote:

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 john@johnmartinez.com 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+
chef-list@gmail.com> 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 cassianoleal@gmail.com
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 GitHub - thommay/chef-encrypted-databags: Handle encrypted databags with a key from S3(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 <
Kevin.Moser@nordstrom.com>
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 - moserke/chef-vault: Development repository for Opscode's chef-vault cookbook). 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
<thom@clearairturbulence.orgmailto:thom@clearairturbulence.org>
Reply-To: "chef@lists.opscode.commailto:chef@lists.opscode.com"
<chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Thursday, April 11, 2013 5:13 AM
To: "chef@lists.opscode.commailto:chef@lists.opscode.com"
<chef@lists.opscode.commailto:chef@lists.opscode.com>
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
<millisami@gmail.commailto:millisami@gmail.com> 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.comhttp://nepalonrails.tumblr.com
http://funsole.com
Sent with Sparrowhttp://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

7

On Apr 12, 2013, at 3:25 AM, Thom May thom@clearairturbulence.org wrote:

Our real problem is that we're not a homogenous EC2 environment, so IAM doesn't work out so well. S3 is a decent solution that's actually accessible for all our nodes, but distributing the keys to sign S3 URIs is a hard problem, too.

So, I'm curious -- does anyone know of any good public key crypto solutions in this space? I believe that traditional encrypted databags have always used symmetric-key algorithms, but then that has the problem of having to securely store and distribute everywhere the same key for decryption that was used for encryption (e.g., 3DES, IDEA, AES).

What about using RSA instead? Or maybe doing at least key exchange with public-key algorithms, so maybe using Diffie-Hellman for that?

Thanks!

--
Brad Knowles brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu