Hi Vlad,
This is all more or less dictated by the auth.conf file, although the
implications can take a little while to chase down. You can see
http://docs.puppetlabs.com/guides/rest_auth_conf.html for the syntax of
this file and its general capabilities. The default rules in Puppet 3.x are
here:
https://github.com/puppetlabs/puppet/blob/master/conf/auth.confMoving on to your concrete questions:
- "Owned" would NOT be able to directly access ANY manifests or Hiera data.
In current versions of Puppet with default auth.conf, it works like this: A
node is allowed to access the /catalog/<NAME> HTTP endpoint, where NAME
*must* be the node's own certificate name. (Nodes cannot access
/catalog/<SOMEONE ELSE>.) A GET request to this endpoint causes the puppet
master to use its manifests and Hiera data to compile a "catalog." (We
mention this here:
http://docs.puppetlabs.com/puppet/latest/reference/lang_summary.html#compilation-and-catalogs)A catalog is not just a subset of manifests; it removes all conditional
logic, irrelevant data, etc., and becomes an unambiguous single-node
document, rather than a contingent multi-node piece of code. All Hiera data
gets resolved, and becomes literal node-appropriate values in the catalog.
- By default, "owned" WOULD be able to access file contents in
<modulepath>/module_name/files. This can be prevented by making additional
rules in auth.conf for specific modules you are worried about.
The default auth.conf allows all certified nodes to access any endpoint
beginning with /file. When fetching file contents for
<modulepath>/my_module/files/this_file.txt, puppet agent hits
/file_metadata/modules/my_module/this_file.txt (to check whether it already
has the correct content) and then
/file_content/modules/my_module/this_file.txt (to fetch the content if it
isn't up to date). These are both prefixed by "/file", so everyone can get
them. Nodes can also use the "file_metadatas" endpoint to get directory
listings.
If you have files in a special module that you are worried about, and if
you can express the nodes who are allowed to access it in terms of
certificate name or IP address, you can create a new auth.conf rule for
that module and place it ABOVE the "/file" rule in auth.conf:
path ~ ^/file_(metadata|content)s?/modules/my_module
auth yes
allow /^(.+)\.dmz\.example\.com$/
allow_ip 192.168.100.0/24
This trick also works for custom fileserver mount points as defined in
fileserver.conf (http://docs.puppetlabs.com/guides/file_serving.html),
which may be a better choice for highly sensitive files.
Finally, for truly sensitive content, you have some extra options:
- You can avoid the "source" attribute for sensitive files, and use
"content" instead. This compiles the approved content for THAT NODE into
the catalog. You can use the template() function
(http://docs.puppetlabs.com/references/latest/function.html#template) to
get content from an external file which nodes cannot directly access, and
if your manifests make sure that only highly trusted nodes will have that
content compiled into their catalogs, the information is effectively
protected from less-trusted nodes that get owned.
- You can investigate the hiera-gpg tool, which... I'm afraid I haven't
learned how to use it, yet, but it promises a fairly robust way to handle
dangerous content.
Also, keep in mind that facts
(http://docs.puppetlabs.com/puppet/latest/reference/lang_variables.html#facts-and-built-in-variables)
reported by the node are not necessarily trustworthy -- If you are using
facts to make decisions about who can access certain content, it may be
possible for an attacker to guess a fact value that will get them something
interesting in their catalog. Note also that the special $clientcert
variable is essentially just a fact; it isn't validated by the puppet
master. We're currently investigating adding a trusted certificate name
variable, see here:
http://projects.puppetlabs.com/issues/19514Hope that helps,
N
On Thursday, May 30, 2013 1:24:27 PM UTC-7, Vladimir Brik wrote:
Hello,
I am trying to better understand the security impact a compromised host
managed by puppet could have on our infrastructure.
Suppose an attacker gained root on a machine called 'owned', and we have
this in site.pp:
node owned {
file {'foo':
content => 'puppet:///modules/module_name/foo',
}
}
Will agent running on 'owned' be able to retrieve:
- <modulepath>/module_name/files/bar
- <modulepath>/module_name/manifests
- hiera data (other than what it's supposed to have access to)
Thanks very much,
Vlad
--
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 post to this group, send email to
[email protected].
Visit this group at
http://groups.google.com/group/puppet-users?hl=en.For more options, visit
https://groups.google.com/groups/opt_out.
