Obviously, a very common problem. And often a very hard one. Here are some suggestions:
-
Encrypted data bags work with chef solo, too. You could copy the data bag key to the computer before the chef run, and delete it once chef solo has converged (be sure to write the code to access the data bag to ignore a missing key, rather than flame out).
-
In some cases, you can eliminate the use of credentials altogether, and improve security at the same time. I'm thinking of Nagios in particular. Sometimes, credentials are unavoidable, but very often, you might be better off using a different mechanism (my Nagios relies heavily on passive checks running in a restricted account that can only access the information it needs via sudo with a carefully crafted sudoers file. Also, check by SSH can be an option).
- For SSH, distribute the keys outside of chef. You usually would have to do that only once. Of course, in very large systems, or for frequently spinning machines up or down, you may run into scalability issues here.
-
For TLS certificates, I only distribute the public key via chef, and the private key manually.
-
You can make distributing TLS and SSH private keys part of your bootstrap process - whatever mechanism you use to install chef-solo can also either generate the private keys, or copy them from wherever you generate them.
Kevin Keane
The NetTech
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html
-----Original message-----
From: Nico Kadel-Garcia nkadel@skyhookwireless.com
Sent: Friday 13th February 2015 16:27
To: chef@lists.opscode.com
Subject: [chef] RE: Re: Using chef solo to aws distribute keys
I've taken a look at the various solutions. None of them work: many are dependent on an available chef server to hold encrypted data, unlocked by a local key, and I'm using chef-solo extensively, not a chef-server/chef-client setup. Also, frankly, many cookbooks such as the "nagios" and "mysql" and "users" cookbooks have no structure in place for managing encrypted data that must be stored on individual nodes in locally unencrypted format, such as MySQL passwords, Nagios stored credentials for remote service checks, or private SSH keys.
It's possible to write individual customized wrapper cookbooks for each of these, but it's awkward and fragile to have to keep wrapping this material. And if you use a git or other source control for such information, it means that anyone who has access to that repository has the relevant passwords or private keys unless you ignore the built-in tools and write your own wrappers or updates to fix this. This is especially true for SSH private keys for individual accounts in the "users" cookbook, and for initial "root" access for MySQL, Postgresql, and other databases.
Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com
-----Original Message-----
From: Noah Kantrowitz [mailto:noah@coderanger.net]
Sent: Thursday, December 18, 2014 10:48 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Using chef solo to aws distribute keysOn Dec 18, 2014, at 3:24 PM, Nico Kadel-Garcia
nkadel@skyhookwireless.com wrote:I was referring more to MySQL database password. This especially applies to
MySQL modules in various web servers and backup systems for databases: these
tend to rely on passwords stored locally in clear text, but I certainly don't want
them in my role or environment attributes in clear text.I've done this with actual chef servers, but am only learning 'chef-solo' now.
I'd welcome a walkthrough or insights.Secrets Management and Chef – Noah Kantrowitz goes over your options.
--Noah