Put Chef Repo into Private Git

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


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 <
Simon.Hawkins@totaljobsgroup.com> 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

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
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

From: Fabien Delpierre [mailto:fabien.delpierre@gmail.com]
Sent: Tuesday, September 15, 2015 8:23 AM
To: chef chef@lists.opscode.com
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 <Simon.Hawkins@totaljobsgroup.commailto:Simon.Hawkins@totaljobsgroup.com> 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


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:

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

nkadel@skyhookwireless.com mailto:nkadel@skyhookwireless.com

*From:*Fabien Delpierre [mailto:fabien.delpierre@gmail.com]
Sent: Tuesday, September 15, 2015 8:23 AM
To: chef chef@lists.opscode.com
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
<Simon.Hawkins@totaljobsgroup.com
mailto:Simon.Hawkins@totaljobsgroup.com> 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

------------------------------------------------------------------------