On Tue, Aug 26, 2014 at 12:27 PM, Erik Dalén <erik.gustav.da...@gmail.com> wrote:
> > > > On 26 August 2014 20:22, jcbollinger <john.bollin...@stjude.org> wrote: > >> >> >> On Monday, August 25, 2014 11:13:40 AM UTC-5, Matt W wrote: >> >>> Comments inline >>> >>> Matt Wise >>> Sr. Systems Architect >>> Nextdoor.com >>> >>> >>> On Mon, Aug 25, 2014 at 6:55 AM, jcbollinger <john.bo...@stjude.org> >>> wrote: >>> >>>> >>>> >>>> On Saturday, August 23, 2014 12:46:59 PM UTC-5, Matt W wrote: >>>>> >>>>> Will, >>>>> Thanks for the response. I know its a bit of a unique model -- but >>>>> when you think about it, it makes a decent amount of sense. We run >>>>> hundreds >>>>> of nodes that are fundamentally similar >>>>> >>>> >>>> >>>> And therein is one of the key problems: "similar", not "identical". If >>>> any node facts (including $hostname, $fqdn, etc.) vary among these hosts >>>> that are identifying themselves to the master as the *same machine*, >>>> then you are putting yourself at risk for problems. Moreover, if security >>>> around your puppet catalogs is a concern for you, then be aware that >>>> positioning your node-type certificates as a shared resource makes it far >>>> more likely that they will be breached. Additionally, you cannot limit >>>> which machines can get configuration from your master. >>>> >>> >>> To be very clear, we do not share certs across nodes. We absolutely use >>> independent certs and sign them uniquely -- in fact, bug #7244 >>> <https://projects.puppetlabs.com/issues/7244> was opened by me >>> specifically for improving the security around SSL certs and auto signing. >>> We make heavy use of dynamic CSR facts to securely sign our keys. >>> >>> More specifically, we've been waiting for the CSR attribute system to >>> allow us to embed the puppet 'node type' (note, not identifier) in the SSL >>> certs so that clients can't possibly retrieve a node type that isn't their >>> own. (Bug #7243 <https://projects.puppetlabs.com/issues/7243>). It >>> looks like this has been finally implemented, so we'll be looking into >>> using it very soon (here >>> <https://docs.puppetlabs.com/puppet/latest/reference/ssl_attributes_extensions.html#extension-requests-permanent-certificate-data> >>> ). >>> >>> >>>> >>>> Lest it didn't catch your eye as it went by, I re-emphasize that Puppet >>>> is built around the idea that a machine's SSL certname is a unique machine >>>> identifier within the scope of your certificate authority. What you are >>>> doing can work with Puppet, but you will run into issues such as the file >>>> naming effects you asked about. >>>> >>>> >>>> >>>>> .. i.e. "this is a web server, it gets the XYZ package installed" and >>>>> "this is a web server, it gets the ABC package installed". Using hostnames >>>>> to identify the systems node-definition makes very little sense and leaves >>>>> quite a bit of room for error. Explicitly setting the node-type as a fact >>>>> allows us to re-use the same node types but for many different >>>>> environments >>>>> and keeps host-names out of the mix. >>>>> >>>> >>>> >>>> Classifying based on a fact instead of based on host name is a fine >>>> idea, provided that you are willing to trust clients to give their type >>>> accurately to the server. Having accepted that risk, however, you do not >>>> by any means need the node-type fact to be expressed to the master as the >>>> node's *identity*. It could as easily be expressed via an ordinary >>>> fact. >>>> >>>> In particular, your site manifest does not need a separate node block >>>> for each node [identity], nor even to enumerate all the known node names. >>>> In fact, it doesn't need any node blocks at all if you are not going to >>>> classify based on node identity. Even if you're using an ENC, it is >>>> possible for it to get the node facts to use for classification. >>>> >>> >>> Using a combination of both our nodes self-identifying themselves as >>> well as the puppet node name architecture allows us to leverage the >>> security of the 'auth' config file, while also having dynamically >>> configured nodes where hostname doesn't matter. >>> >> >> >> >> >>> Realistically, hostnames are a terrible method for security ... someone >>> could always break into a 'www' server and rename it to 'prod-db-thingy' >>> and have it match the regex and subsequently get the database puppet >>> manifest. (Just as a stupid simple example). >>> >>> >> >> No, they couldn't. By default, Puppet relies on nodes' *certnames* to >> identify them. That the agent uses hostname as certname by default is a >> convenient irrelevance once the master signs the node's certificate. >> Changing a node's hostname does not enable that node to get a different >> node's configuration, at least not under Puppet's ordinary configuration, >> because its certname does not change. A node's certname cannot change >> without the CA's participation. >> >> >> >>> For what its worth, our old model was a single 'default' node type and a >>> simple fact ('base_class=my_web_server'). This worked extremely well, but >>> left us more open to basically any client being able to request any catalog >>> compilation. The auth-file in this world was effectively useless for >>> preventing already-verified nodes from doing bad things. >>> >> >> >> So you want to maintain information on the master that informs it what >> configuration(s) your nodes are permitted to request, but within those >> limits you want nodes to be able to request different configurations? It >> seems like you could have added such a validation pretty easily to your old >> scheme, and it might still be to your advantage to do so. It would be easy >> to record in Hiera either which configurations each node is permitted to >> request, or which nodes (by certname) are permitted to request each >> configuration. >> >> >> >>> Can you say a bit more about that? What do you see that suggests agents >>>> are pulling down "node information" other than their catalogs (and later, >>>> any 'source'd files)? >>>> >>>> >>> With nearly every puppet catalog compile, we also see GET requests like >>> this: >>> >>> 10.216.61.76 - XXX - puppet "GET /production/node/xyz? HTTP/1.1" 200 >>>> 13733 "-" "-" 0.021 >>> >>> >>> Where 10.216.61.76 is *not* the local IP of the puppet master... its the >>> remote IP of the ELB, which indicates that its remote traffic from our >>> puppet clients. >>> >>> >> >> That traffic might be coming from nodes, but all you know for sure is >> that it is traversing the ELB. Surely the master could send requests >> through the ELB that end up coming back to it. For all I know, the ELB >> might preferentially route such requests back to the originating host. >> >> From the perspective of the Puppet service lifecycle, the two most likely >> sources of such traffic are (1) an ENC retrieving node facts, and (2) the >> master determining nodes' environments. I don't know any reason why nodes >> would be requesting their own node information, and even if they did, I >> can't see how that would affect the catalog the master serves to them. >> > > The reason for them to do this is to be able to use the environment that > was configured on the master to fetch the plugins from. So first it tries > to fetch its node info from the master to see if the environment in that is > different than what it had configured locally. This is a new feature since > puppet 3.0. > > In puppet 2.7 it used the fact plugins from the agent configured > environment and the catalog from the master configured if I remember > correctly. > Yes, and also file resources came from the agent-configured environment even though the resource was from the master-configured environment, which resulted in much hilarity. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAGUqgV9RDGWfXSwBBFaQf%2BP_7V7DgK7EFZP25SfwE8%2Bi9iDKMg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
