On Jan 22, 2013, at 3:04 PM, jcbollinger <john.bollin...@stjude.org> wrote:
>
>
> On Tuesday, January 22, 2013 7:08:09 AM UTC-6, Boyan Tabakov wrote:
> Hello,
>
> Let's consider the scenario when a client node in a puppet environment
> gets compromised.
>
> In case some of the puppet modules make decisions based on agent facts,
> these modules are potentially exposed to abuse from the malicious puppet
> agent.
>
> For example, if a class has:
>
> if $some_fact == 'some value' {
> # deploy some configuration
> }
>
> then the compromised node could send falsified value of that fact to
> obtain configuration that potentially contains secrets (private keys,
> passwords, etc) that was meant only for other nodes.
>
> AFAIK, the only authenticated piece of information that a puppet agent
> passes to the puppetmaster server is the name of the node, as specified
> in the SSL certificate for the agent. However, the value of $fqdn, as
> seen in a manifest / class on the puppetmaster seems to be based on the
> agent-supplied fact 'fqdn'.
>
> Having said that, then can the value of $hostname be trusted to come
> from the identity in the agent's SSL certificate? What are best
> practices for ensuring that a compromised agent can't access
> configuration meant for different nodes?
>
> Are an ENC or external data sources (Hiera) designed to provide trusted
> puppetmaster-side metadata for nodes? Is that the way to go?
>
>
>
> You are correct that that only the identity of the client node is
> authenticated by Puppet, and even that only insomuch as the client can be
> relied upon to protect its SSL certificate. The $hostname fact cannot be
> relied upon to convey that information, as it doesn't in any sense need to be
> the same thing; you're looking for $certname. It is, however, $certname (not
> $hostname) by which a node block is selected and/or an ENC queried, so
> Puppet's architectural foundation is secure in that regard.
>
> You are also right that a compromised client can, in principle, falsify the
> fact values presented to the master in an attempt to make it divulge secret
> information. Whether the master might actually divulge anything is a
> function of the manifests with which site administration has configured it.
> In other words, that's a question of how Puppet is used, not of the
> fundamental security of Puppet itself.
>
> To the extent that you want to record server-side node data, I think hiera is
> the way to go. I prefer that to encoding data in an ENC or in your
> manifests, but those are some of the other options. All of those are secure
> to the extent that the master itself is secure, though I wouldn't say that
> any of them were designed specifically as a secure alternative to node facts.
>
>
> John
>
Several months ago I created a feature request which basically requested the
ability to flag certain facts as 'should never change' and have the ability to
trigger different behaviors in on the master if $node delivers its facts with
those items different…
https://projects.puppetlabs.com/issues/13934
if a node reports memory changed, you might want to send an email (IE: a dimm
failed, the box panic'ed and rebooted, and now has less memory). This could be
done with other methods and tools, this feature doesn't need to be implemented
to facilitate that (nor is it necessarily the best tool for the job), but if a
node reports that it's fqdn, or '$proprietary_fact' is now different, you may
want the master to full-stop on catalog compilation and flag the node as
problematic and notify you, as someone may be doing something nasty.
you can also use an enc and base lookups off of $certname, as you can trust
that you signed that cert at some point in time (assuming you don't have auto
signing enabled) and so that should be trusted as legitimate.
if you have auto-signing enabled though, this could give someone a path into
nefariousness.
W
________________________________
This message may contain confidential or privileged information. If you are not
the intended recipient, please advise us immediately and delete this message.
See http://www.datapipe.com/legal/email_disclaimer/ for further information on
confidentiality and the risks of non-secure electronic communication. If you
cannot access these links, please notify us by reply message and we will send
the contents to you.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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.
