[chef] Re: Re: Re: Re: Sensitive Data w/ Solo

[Ruby Newbie < >]

Ohai, Michael.

On Jun 18, 2010, at 3:09 PM, Michael Guterl wrote:
> I have created a gist with the bootstrap.sh script I'm using:
> https://gist.github.com/557d9694a9606b9edbeb
OK, now it's clear what you're trying to do -- thanks.

> ...
> however, storing the text of the keys in the bootstrap script seems
> wrong.
"Wrong" from a security standpoint, correct? In my opinion, storing the 
private key data in your bootstrap script is not so bad -- *if* the bootstrap 
script is not part of your generic disk image, and is instead copied over 
secure a channel to the node at boot time. In this case, you're really 
treating the whole bootstrap script as "secret data". Since the script is not 
that long or complex (and therefore presumably not *too* subject to rapid 
change), this may work OK for you. 

That said, most of us would try to separate the secrets from the code that 
acts on them, for reasons mentioned earlier in this thread.

> Is anyone dealing with anything similar?
Yes -- I think that everyone who makes substantial use of Chef must 
eventually confront the following issue, whether using chef solo or full 
client-server...

Chef needs to handle the secret data that your applications use (regardless 
of when that data gets inserted into your workflow). So we all use some kind 
of "meta-secret" to protect that data. In the client-server setup, the 
validation.pem (or individual client.pem) represents the meta-secret. In your 
case, it's the private half of your GitHub repo. In either case, if this data 
is compromised, so is all the secret data that Chef works with to configure 
your nodes.

For this reason, the best practice it to NOT store this meta-secret (or 
indeed any secret data) on your generic disk image, but to instead pass the 
data to the node at boot time, and if possible, to remove it after 
convergence. That's why Chef's knife tool can generate Amazon EC2 launch data 
containing the "meta-secret". You can follow the same security model with 
chef-solo, if you make a rake task in your Chef repo that carries out the 
following steps:
1) Use your cloud provder's API, or your virtualization host's API, or 
whatever else you need to boot a fresh system, and store it's IP address.
2) Use 'scp' (or Ruby's Net::SCP, or whatever) to transfer the private key 
data (or the entire bootstrap script, if you must) to the node.
3) Use 'ssh' (or Net:SSH) to run you bootstrap script.
4) Use 'ssh' to DELETE THE GITHUB PRIVATE KEY FROM THE NODE! (or do so from 
the bootstrap script)

Make sense?
-RN