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


Chronological Thread 
  • From: Erik Kastner < >
  • To:
  • Subject: [chef] Re: Re: Sensitive Data w/ Solo
  • Date: Thu, 17 Jun 2010 13:21:03 -0400
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=HzgUOlXZXxC76+vC3nrxt46fh192PCueFoywA0DSffB0FpH7dfLli1kykwuID2/Rjb I8iSb2HTb/kLpo3alv+fVn6fWh+6QaXV21gQAzpNDd4CNSduxb7HXA5Nsv7v9TP+xi84 yfo+XcB28p6O9Jz72dVtIwGdxLdhYQF7NjRKI=

I'm not using this too much yet, but I like storing hashed passwords
and public keys. Neither are super sensitive (the hashed passwords are
more so, but not so sensitive I'd be totally against keeping them in a
repo on my private network). To generate passwords that work: openssl
passwd -1
(got that from here:
http://github.com/37signals/37s_cookbooks/blob/master/users/attributes/default.rb)

The one thing I haven't figured out is how to store a hashed password
for mysql :)


On Thu, Jun 17, 2010 at 12:59 PM, Ruby Newbie 
< >
 wrote:
> Ohai, Michael.
>
> On Jun 17, 2010, at 12:25 PM, Michael Guterl wrote:
>> I'm curious how others are handling sensitive information (passwords,
>> ssh keys, etc) that may be part of a chef cookbook
> For now, I have been keeping such data a 'secrets' directory that is 
> located within my Chef operations repo, but is not actually *part* of the 
> repo (using gitignore). Most of the secrets are contained in a JSON file, 
> as Chef attributes, but there are also some flat files (the current Chef 
> server validation.pem, apache SSL certs, etc.), which are used by other 
> software systems, in addition to chef-client (like knife).
>
> When I run 'rake roles', all of the JSON data gets read into the 
> override_attributes of a special 'deployment-secrets' role, by custom ruby 
> code in the role file -- something like this:
> =============================
> name "deployment-secrets"
> description "Credentials and other sensitive attributes"
>
> # The JSON secrets are in a 'chef' subdirectory of the secrets folder
> OPS_DIR = File.expand_path(File.join(File.dirname(__FILE__), ".."))
> SEC_DIR = File.join(OPS_DIR,"secrets")
> SECRETS_FILE = File.join(SEC_DIR, 'chef', "chef-secrets.json")
>
> # Load secrets from JSON data if present
> secrets = Hash.new
> if File.exists? SECRETS_FILE
>  Chef::Log.debug "Loading template-specific secrets from #{SECRETS_FILE}..."
>  secrets = JSON.parse(File.read SECRETS_FILE)
> end
>
> # Load some data from a flat file and encode it as JSON
> # Merge it into the 'secrets' hash
> ...
>
> # Use the secrets hash as the override attributes of this role
> override_attributes secrets if not secrets.empty?
> =============================
>
>
> You can also copy flat files from the secrets directory into cookbooks at 
> this stage:
> =============================
> puts "Copying SSL certificates into comapny cookbook..."
> RSYNC = "rsync --exclude '.*' --copy-links -vprt"
> COMPANY_SSL_RECIPE="#{OPS_DIR}/site-cookbooks/my_company"
> rsync_cmd = "#{RSYNC} #{SEC_DIR}/ssl/ 
> #{COMPANY_SSL_RECIPE}/files/default/ssl/"
> `#{rsync_cmd}`
> =============================
>
>
> The benefits of this system are:
> 1) Operational secrets are stored separately from the main configuration 
> repo in a DRY way. The usual 'rake install' process takes care of inserting 
> all secrets into the regular workflow, for both chef-client and chef-solo.
> 2) Different sets of operational secrets (for developers, testers, and 
> production ops personnel) can be maintained for different environments, and 
> symlinked into place as desired.
>
> The drawbacks are:
> 1) Storing secrets as attributes is not so secure in the first place; and
> 2) All secrets are stored on all nodes, regardless of whether they're 
> needed on that particular node. This makes this system even less secure.
> 3) More I haven't thought of...?
>
> Hope this helps,
> - R. Newbie
>
>
>



Archive powered by MHonArc 2.6.16.

§