FAQ
Nick,

Thank you very much for the detailed explanation!

Vlad
On 05/30/13 20:09, Nick Fagerlund wrote:
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 4 | next ›
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 30, '13 at 8:26p
activeMay 31, '13 at 2:01p
posts4
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase