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

[Michael Guterl < >]

On Fri, Jun 18, 2010 at 8:05 PM, Ruby Newbie 
<
 >
 wrote:
> 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.
>
You make a very good point here, I guess my biggest worry was sharing
the SSH keys across multiple machines.  Being the key will only be
used for access to the repository, this probably isn't as big of a
deal.

> 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.
>
This makes sense, I'm still thinking through the solution you propose
in your two earlier replies.

>> 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.
>
This was perhaps my biggest concern from a security standpoint;
gaining access to our chef repository could open up access to our
entire infrastructure.  My knowledge of security is not very strong
and prior to getting too deep into Chef, I wanted to make sure I
wasn't making any obvious blunders with securing our installation.

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

I can't thank you enough for the insight and advice you have provided,
it is VERY much appreciated.

Best regards,
Michael Guterl