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 <[email protected]> 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 <[email protected]> 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 [email protected]. >> 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 [email protected]. > 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 [email protected]. 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.
