One thing to consider is using hiera e-yaml gpg based on certnames. You can put secrets (db passwords etc) here and they are matched to the SSL certname. In this configuration an attacker can change their role/profile but still cant access secrets for a particular node that doesn't match its certname.
That is not the only way but a fairly reasonable compromise. Den > On 13 Feb 2015, at 09:43, Alex Elman <zombied.proc...@gmail.com> wrote: > > I don't think you should limit your agent's ability to dictate what resources > should be configured and served. The Puppet client-server trust model is > fairly flat and this provides a decent trade-off between flexibility and > security. If your agent is owned, then as you mention, you have bigger > concerns. > > You do have some decently granular control over which agents get access to > which resources by using auth.conf. See > https://docs.puppetlabs.com/guides/rest_auth_conf.html. Configuring auth.conf > on the master side, you can lock down certain resources using allow/deny > directives or ACLs for things other than facter facts like hostnames and ip > addresses. I would make sure you lock things down against unauthenticated > agents at the very least. Also be judicious about how you design your > auto-signing configuration if you're worried about rouge agents. See > https://docs.puppetlabs.com/puppet/3.7/reference/ssl_autosign.html. > > -Alex > >> On Thu, Feb 12, 2015 at 4:10 PM, UK_beginner <simon.han...@gmail.com> wrote: >> I'm new to puppet and have been exploring different ways of configuring >> manifests, ranging from huge single manifests, through per-node and am >> currently looking at the role/profile patterns. >> >> One thing I've been looking at is using a mix of puppet and hiera to set up >> a hierarchy based around server roles (i.e. web. database, logging etc.) >> using the environment and a custom fact set on the agents using >> /etc/facter/facts.d. For me this seems an efficient way to describe a >> configuration since it can avoid a lot of duplication. >> >> However, some of the team I'm working with have concerns around the fact >> that we're letting the agents dictate what manifests get passed to them >> since they define the role & environment facts. I've been told that if >> someone found a 'root-level' exploit they could change the facts to retrieve >> whatever manifest they want - my response is if we get to that stage, all >> bets are off since they can just stop puppet, download rpm's etc. >> >> However I wanted to gauge the feeling of the experts - is this a risky >> solution, or do others feel that as we implement other security factors >> (firewalls, correct file permissions, certificates) that this is an >> acceptable route to investigate? >> >> Thanks in advance for you thoughts. >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-users/b24c11a0-1e0a-459f-9873-de80fccd41a9%40googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > > -- > Alex Elman > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/CAD-8G_pnMVcpK76OaKWVNcw6PM%3Dsv8enSDX_SHxxXyhUXg1fCg%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/57237023-2022-40F7-B508-56FD3830EB08%40gmail.com. For more options, visit https://groups.google.com/d/optout.
