... | ... | @@ -605,6 +605,26 @@ as well. |
|
|
|
|
|
## Getting information from other nodes
|
|
|
|
|
|
A common pattern in Puppet is to deploy resources on a given host with
|
|
|
information from another host. For example, you might want to grant
|
|
|
access to host A from host B. And while you can hardcode host B's IP
|
|
|
address in host A's manifest, it's not good practice: if host B's IP
|
|
|
address changes, you need to change the manifest, and that practice
|
|
|
makes it difficult to introduce host C into the pool...
|
|
|
|
|
|
So we need ways of having a node use information from other nodes in
|
|
|
our Puppet manifests. There are 5 methods in our Puppet source code at
|
|
|
the time of writing:
|
|
|
|
|
|
* Exported resources
|
|
|
* PuppetDB lookups
|
|
|
* Puppet Query Languaeg (PQL)
|
|
|
* LDAP lookups
|
|
|
* Hiera lookups
|
|
|
|
|
|
This section walks through how each method method works, outlining the
|
|
|
advantage/disadvantage of each.
|
|
|
|
|
|
### Exported resources
|
|
|
|
|
|
Our Puppet configuration supports [exported resources](https://puppet.com/docs/puppet/latest/lang_exported.html), a key
|
... | ... | @@ -683,7 +703,8 @@ Note that there is a potential security issue with that approach. The |
|
|
same way that exported resources trust the exporter, we trust that the
|
|
|
node exported the right fact. So it's in theory possible that a
|
|
|
compromised Puppet node exports an evil IP address in the above
|
|
|
example, granting access to an attacker instead of the proper node.
|
|
|
example, granting access to an attacker instead of the proper node. If
|
|
|
that is a concern, consider using LDAP or Hiera lookups instead.
|
|
|
|
|
|
Also note that this will eventually fail when the node goes down:
|
|
|
after a while, resources are expired from the PuppetDB server and the
|
... | ... | @@ -691,6 +712,10 @@ above query will return an empty list. This seems reasonable: we do |
|
|
want to eventually revoke access to nodes that go away, but it's still
|
|
|
something to keep in mind.
|
|
|
|
|
|
Keep in mind that the `networking.ip` fact, in the above example,
|
|
|
might be incorrect in the case of a host that's behind NAT. In that
|
|
|
case, you should use LDAP or Hiera lookups.
|
|
|
|
|
|
Note that this could also be implemented with a `concat` exported
|
|
|
resource, but much harder because you would need some special case
|
|
|
when no resource is exported (to avoid adding the `deny`) and take
|
... | ... | |