Michael DeHaan wrote:
One way to handle this would be by keeping confidential information in a
seperate version control repository (not public), rather than in your
main one. Puppet has a system of module paths so you could keep your
confidential info seperate from the content you would want to give to
everyone who would normally be working with Puppet, and check *both* of
these out on the Puppet server. For development systems/testing, you
could just check out a copy of a different repo, with testing/stage
credentials in the modules instead.
You could also use a custom function to pull this information from other
sources for accessing a keystore server side, though I'd be curious to
what those other services might be.
How is everyone else handling this?
We have a filerserving module named "private" that is defined like
[private]
path /config/private/%h
allow *
in fileserver.conf. Each client gets its own subdirectory
"/config/private/client1", "/config/private/client2", and so on.
In there we stuff things like SSH host keys, X.509 host certificates,
license keys, and other secret data, and let Puppet install them via
file {
"/etc/ssh/ssh_host_rsa_key":
source => "puppet:///private/ssh_host_rsa_key", ...;
}
We currently don't have /config/private under version control, but
if we did it would definitely be in a separate repository from
our manifests.
/Bellman
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
