Private data in manifests (was: Re: [Puppet Users] Using Git to distribute Puppet configs)

[Eric Gerlach]

On Wed, Jan 27, 2010 at 05:59:27PM +0100, Thomas Bellman wrote:
> >- Each node has a copy of the entire repository of modules and classes
> >which makes it in my opinion a security risk.
>
> Don't put passwords and private keys in your manifests.

Would you call this a general rule? If so, what's the best practice for
setting passwords and private keys?

Cheers,

--
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: eger...@feds.uwaterloo.ca

[Peter Meier]

> On Wed, Jan 27, 2010 at 05:59:27PM +0100, Thomas Bellman wrote:
>> >- Each node has a copy of the entire repository of modules and classes
>> >which makes it in my opinion a security risk.
>>
>> Don't put passwords and private keys in your manifests.
>
> Would you call this a general rule? If so, what's the best practice for
> setting passwords and private keys?

if your setup has a puppetmaster I would use a function to do an
external lookup. hence your manifests contain only the lookup
statement and the passwords are only stored on the master. SOON to
come: a tool doing that for you with puppet integration...

regarding private keys: we have them stored in special module, which
is only stored on the master. It is in a git repo, however we don't
share it outside the master. So if you need add/change a key you have
to do that on the master. However all the manifests describing which
keys go where, is still done in the usual modules.

cheers pete

[Thomas Bellman]

Eric Gerlach wrote:

> On Wed, Jan 27, 2010 at 05:59:27PM +0100, Thomas Bellman wrote:

>> Don't put passwords and private keys in your manifests.

> Would you call this a general rule? If so, what's the best practice for
> setting passwords and private keys?

Yes, I think that is a very good general rule.

I would recommend putting private keys and similar stuff in a separate
fileserver section, preferably one that is client specific, i.e. where
you have %H in the path:

[private]
path /config/private/%h
allow *

and copy files from there with something like:

file {
"/etc/ssh/ssh_host_rsa_key":
source => "puppet:///private/sshkeys/ssh_host_rsa_key";
}

If it's not practical to manage the entire file, for example if you just
want to set the password of a particular user, then you can grab that
data on the Puppet master using the file() or template() function, or a
custom function pulling the string from some kind of structured file or
database. Something like:

define user_password()
{
$password = file("/config/user-passwords/$name")
user {
$name:
password => $password;
}
}

might do the trick.

There are a couple of advantages to keep that kind of data out of the
manifests. One is that you don't "contaminate" non-sensitive information
(your configuration) with sensitive data. Even if you don't plan on
showing your manifests to the public, you might someday want to get help
from external people. If passwords and private keys are kept separate,
you don't need to go through your manifests and censor them before showing
them to the helpers.

Also, if you have a testing/development system, you probably don't want
the same passwords and keys on that as you do on the production system.
Moving new manifests from testing to development becomes easier if you
don't have to change passwords and keys in them at the same time.

Secondly, in my experience it doesn't make much sense to track keys in
the same VCS repository as configuration. If you suddenly decide that
you need to revert your configuration to what it was two weeks ago, do
you really want to revert, e.g., ssh host keys at the same time?

/Bellman

[Sylvain Avril]

I use the following plugin :

module Puppet::Parser::Functions
newfunction(:getPassword, :type => :rvalue) do |args|
clientHostname = args[0]
type = args[1]
len = args[2]
filename = "/var/lib/puppet/passwords/" + clientHostname + "-" +
type + ".pass"

def newpass( len )
chars = ("A".."Z").to_a + ("a".."z").to_a + ("0".."9").to_a
newpass = Array.new(len) { chars[rand(chars.size)] }.join
return newpass
end

thePass = ""
if File.exist? filename
theFile = File.new(filename, "r")
theFile.each_line {|line| thePass = line }
theFile.close
else
thePass = newpass ( len.to_i )
theFile = File.new(filename, "w+")
theFile.print thePass
theFile.chmod(0600)
theFile.close
end

return thePass
end
end

It store the password on the puppetmaster and you can have it as a
variable with :
$adminPassword = getPassword($hostname, "myapppass", "12")

[Ohad Levy]

On Sat, Jan 30, 2010 at 12:23 AM, Peter Meier <peter...@immerda.ch> wrote:

On Wed, Jan 27, 2010 at 05:59:27PM +0100, Thomas Bellman wrote:

>- Each node has a copy of the entire repository of modules and classes
>which makes it in my opinion a security risk.

Don't put passwords and private keys in your manifests.

Would you call this a general rule?  If so, what's the best practice for
setting passwords and private keys?

if your setup has a puppetmaster I would use a function to do an external lookup. hence your manifests contain only the lookup statement and the passwords are only stored on the master. SOON to come: a tool doing that for you with puppet integration...

do you mean extlookup or something else?
 

regarding private keys: we have them stored in special module, which is only stored on the master. It is in a git repo, however we don't share it outside the master. So if you need add/change a key you have to do that on the master. However all the manifests describing which keys go where, is still done in the usual modules.

This might have scaling problems (e.g. when you have more than one puppetmaster).
we actually created a simple datastore which is encrypted (reusing puppet certificates and preshared key) to allow our masters to decrypt info which is consider confidential.

cheers,
Ohad

[Christian Kauhaus]

Ohad Levy schrieb:

> we actually created a simple datastore which is encrypted (reusing
> puppet certificates and preshared key) to allow our masters to decrypt
> info which is consider confidential.

This sounds interesting. Could you give a code example?

Cheers

Christian

--
Dipl.-Inf. Christian Kauhaus <>< � k...@gocept.com � systems administration
gocept gmbh & co. kg � forsterstra�e 29 � 06112 halle (saale) � germany
http://gocept.com � tel +49 345 1229889 11 � fax +49 345 1229889 1
Zope and Plone consulting and development