[chef] Re: RE: Re: Put Chef Repo into Private Git

[Lamont Granquist < >]

    The new database/mysql/postgresql cookbooks should be offering
    LWRPs.  What you put into those LWRPs is up to you, it can come from
    hard-coding in the recipe, or attributes, or search or [encrypted]
    data bags.  This is one of the strengths of the approach of removing
    attributes and recipes from library cookbooks and just exposing
    resources.  With Chef 12.0 the API to read from encrypted data bags
    is also now the same as the API to read from data bags -- it knows
    if it is encrypted or not.
    
    It is a Best Practice at this point to use Encrypted Databags, along
    with Chef Vault to store database secrets.  This protects you
    against compromise of any of your Chef nodes (which do not have
    privs to decrypt the data bag) and compromise of the Chef Server
    (although compromise of the Chef Server will typically lead to
    compromise of the whole infrastructure, but in a situation where the
    attacker has a read-only database dump of the Chef Server, those
    secrets will be protected).
    
    Simply write your recipes that use the database and mysql/postgresql
    resources to use a data bag, then encrypt that data bag with Chef
    Vault.

On 09/21/2015 07:54 AM, Nico Kadel-Garcia wrote:

" type="cite">

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: ]
Sent: Tuesday, September 15, 2015 8:23 AM
To: chef ">< >
Subject: [chef] Re: Put Chef Repo into Private Git

 

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.

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!

Fabien

 

 

On Tue, Sep 15, 2015 at 4:05 AM, Simon Hawkins < " target="_blank"> > wrote:

Hi All,

 

I have my chef-repo on my chef-workstation with the usual directories:

 

/home/chefuser/chef-repo

config

cookbooks

data_bags

environments

 

etc,

 

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?

 

Cheers,

Simon

 

---

Disclaimer

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

---