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.conf
Moving 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/19514 Hope 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.
