On 05.07.2013 15:13, Jakov Sosic wrote:
On 07/05/2013 02:46 PM, David Schmitt wrote:
One of the big arguments for puppet is the unifying aspect of devs and
ops to use the same tool/language/process, which improves cooperation,
agility and quality of the work. This indicates that your application
deployment should be integrated into your puppet manifests and those
manifests should be integrated into the application development/release
cycle.
But how are they integrated in your environment? What would you do in my
case?
In the environments I support everything is deployed through puppet.
This leads to a big unification in dev/test environments. Through
vagrant the complete stack can be tested locally before pushing to code
review. From there the code travels through gerrit and jenkins until it
is deployed to the puppetmaster.
Did I offend you some how with my OP? If I did, I'm really sorry, that
was not my intention.
At no point I was offended by your words. I noticed a weakness in your
explanation and frankly (even ruthlessly) addressed it. Please accept my
apology for my rudeness.
This is a non-issue as the deployment process will always be able to
push the changes it needs into the system. So a subversion (no pun
intended) of the deployment process will always be a death knell,
independent of the used tool. So either the devs have the need and right
to modify those configuration files, or they don't. If they have the
need and right, then they also share the responsibility for the system.
Yeah, but things have to stay pretty tight. For example: if you enable
some user account to push files into dot-d directory, not-if-but-when
that account gets broken into, you have a possibility of privilege
escalation.
What is the risk of having an attacker who breaks into the deployment
user (which should only do deployment and nothing else), but is not able
to achieve root directly? A kernel exploit would yield root. Exploiting
a running daemon over the network is out, since the deployment user
doesn't run daemons (use locked down sudo to trigger service restarts).
One possibility would be a symlink race against one of the deployment
scripts to subvert the deployed code. Without knowing your actual threat
profile, I'd say that that would be pretty unusual for an attacker to
custom craft such a local cross-user exploit against a locally developed
script set.
So, allowing the write privilege for that directory obviously is not a
good choice.
It's a very fine line to walk. Perhaps an API (even a little script that
does syntax checks and/or auditing) might suffice.
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.
