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[1],recipe[2]’’ –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. Nico Kadel-Garcia Lead DevOps Engineer From: Fabien Delpierre [mailto:
Simon, Yes and no. It's trivial to turn your existing directory into a Git repo and push it to your private GitHub server. https://help.github.com/articles/adding-an-existing-project-to-github-using-the-command-line/ 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.
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! Fabien On Tue, Sep 15, 2015 at 4:05 AM, Simon Hawkins <
" target="_blank">
> wrote:
|
Archive powered by MHonArc 2.6.16.