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.
