Very few cookbooks are written to protect credentials well, nor are many written to support the use of encrypted data bags. Cookbooks that use clear text credentials include:
database cookbooks – database credentials, notably ‘mysql’ and ‘postgresql’
monitoring cookbooks – local service credentials, notably ‘nagios’ and ‘nrpe’ and ‘snmp’
AWS credentials – individual user credentials, notably ‘aws’ and ‘awscli’
SSH credential handling cookbooks – plain-text published private SSH keys, notably ‘rsnapshot’ and ‘users’. ‘users’ uses data bags, but has no option to use encryption, nor to use encryption only for the SSH keys to ease legibility of the database.
Protecting credentials seems to have been an afterthought, not a default requirement for most cookbooks. Even the use of encrypted data bags often begs the question of “how do you securely deploy the secret for the encrypted data bags”. As things exist right now, the chef server and any source controlled configuration repositories or chef server backups often contain quite a few private credentials and can represent a profound security vulnerability.
I’ve previously heard the theory that “it’s OK, only the specific client would have that data available”. This is generally not true, because clients can use the “chef-client –o ‘recipe,recipe’’ –E ‘environment1’ ” options to run non-standard cookbooks and get the plaintext configuration files written to their individual system. This is also one of the subtle security risks when development or less secure environments are managed by the same chef server as a critical, production environment. While those less secure chef clients generally do not have the privileges to modify the chef server, they can pull a surprising amount of information from the server with their client credentials.
There are some useful approaches to work around this: one of mine is to ensure that new hosts generate new SSH hostkeys when deployed, and use the host’s own private SSH hostkeys as passphrase free SSH keys for the root user. That way, they can be audited without chef involvement, they can be verified by the ordinary user at the command line with the “ssh-keyscan” command, and can be used for privileged tools like ‘rsnapshot’ that already run as the root user. But that doesn’t lend itself well to publishing a shared private key, nor does it help with mysql or postgresql admin user passwords.
Lead DevOps Engineer
From: Fabien Delpierre [mailto:firstname.lastname@example.org]
Sent: Tuesday, September 15, 2015 8:23 AM
To: chef email@example.com
Subject: [chef] Re: Put Chef Repo into Private Git
Yes and no.
It’s trivial to turn your existing directory into a Git repo and push it to your private GitHub server.
Before committing, you may want to set up a .gitignore. If you have any secrets in your data bags, think about whether they should be in source control.
Making your Chef server use that Git repo is a little trickier. Somehow you still need to upload data from the repo to the Chef Server by using Knife. The data is not stored in Chef Server the same way it’s stored in the Chef repo on your workstation. You could set up a CI workflow with something like Jenkins and/or Travis CI that would keep an eye on the GitHub repo and upload changes to the Chef Server. It’s not hard to do but is a little more involving than adding the Chef repo to GitHub.
Just an example: https://blog.5apps.com/2014/01/07/using-travis-to-make-sure-your-chef-repo-and-server-are-in-sync.html
I hope this helps!
On Tue, Sep 15, 2015 at 4:05 AM, Simon Hawkins <Simon.Hawkins@totaljobsgroup.commailto:Simon.Hawkins@totaljobsgroup.com> wrote:
I have my chef-repo on my chef-workstation with the usual directories:
Is there a way I can create a repository on our private github server and upload this whole directory structure and get my chef-server and workstation to use this repo? Are there any guides on how to do this?
This message is intended only for the use of the person(s) (“Intended Recipient”) to whom it is addressed. It may contain information which is privileged and confidential. Accordingly any dissemination, distribution, copying or other use of this message or any of its content by any person other than the Intended Recipient may constitute a breach of civil or criminal law and is strictly prohibited. If you are not the Intended Recipient, please contact the sender as soon as possible.
Totaljobs Group Limited Registered Office: Bluefin Building, 110 Southwark Street, London, SE1 0TA, UK Registered in England and Wales under company no. 4269861