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