On Mon, 25 Apr 2011 19:10:35 -0700, Matt Wise wrote: > > I'm working out some security issues here and wanted to throw > something out there... I'll be digging in tonight to see whether > something like this is possible, so I'd appreciate feedback quickly if > anyone happens to know if this is possible. Imagine a scenario where > our individual hosts actually tell the puppet server which 'config' > they want. This is our environment, and its not changeable. (The short > explanation — its done this way because we provision nodes in several > clouds where hostnames are not known until after a host has booted). > For now, our nodes actually check in and say "I want XYZ class". > > I'd like to have our nodes able to do this ONCE ... only when they > generate their CSR. After that, I'd like their 'base_class' to be > embedded in the CSR (And subsequently the CERT), so that a client > cannot later change its mind about what kind of host it is. > Essentially I'm thinking the process would be something like this: > > Client: > -) fill in 'base_class' somewhere (puppet.conf?) > -) run puppet... host generates private key, and csr, and submits it to the > puppet ca master > > Server: > -) process signs CSR and provides Cert back to host (this is automated in > our case, but not with autosign.conf) > > Client: > -) begin actual puppet run.. request real configuration > > Server: > -) read 'base_class' from certificate, and fill in $base_class with that > data .. > > > Thoughts? Any ideas on a good way to work this out? > > (my alternative method is going to involve a back-end Amazon SimpleDB > script that dumps a nodes base_class into the database the first time > ti runs, and then forever-after pulls from SimpleDB to fill in the > base_class variable. I dont like this though, as its slow and it adds > another service dependency.) > >
I know you've stated that this is your configuration, and it's not changeable, but I'm still confused about what lead you to this setup. I assume that you can "trust" the puppet master(s). Given that you can generate certificates for arbitrary cert names, how does not knowing the host name of a node until after it boots matter? It seems like just generating cert names that weren't the same as the host name would give you all the security you're looking for, and would solve the classification problem since the 'node name' would be known before-hand (manifests match on cert name not host name, they're just usually the same). Is there something about the provisioning process that prevents pre-generating the certs, and placing the cert & an appropriate puppet.conf on the machine before first boot? (This would definitely explain why this approach would be un-workable.) -- Jacob Helwig
signature.asc
Description: Digital signature
