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: egerl...@feds.uwaterloo.ca

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

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

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")

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

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

Ohad Levy schrieb:

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