On 2013-07-05 20:49, Jakov Sosic wrote:
It's a very fine line to walk. Perhaps an API (even a little script that
does syntax checks and/or auditing) might suffice.
One thing that did cross my mind is to allow deployment process to push
specific files to specific locations on puppet master. That way, after
the files are injected into master, all the deployment tool has to do
afterwards is to initiate agent run on each node.
What do you think about that idea?
If the deployment user can push to the puppetmaster it only increases
the attack surface.
Another idea: the configurations get deployed to a central (git) repo
and puppet pulls the updates from there. That way the deployment process
never touches the puppet master, the dot.d is still under developer
control, but not reachable from the local deployment UID.
If that's the level of paranoia you need to apply, don't forget to audit
other attack vectors like init scripts, setuid binaries and things that
can be affected by subverting the application itself.
Regards, David
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
