Oh and to add to my message. The benefit of this is there is no tomfoolery with multiple CAs and the confusion that will cause. If the concern is about letting one puppet client connect to two different pools then you can limit who can retrieve their catalog either through the auth.conf or directives via apache/nginx directives.
The only time a new CA would be required is if you cant isolate via auth.conf or apache/ngnix and that would depend on the topology of your network. If you are concerned with a rogue server then you have autosign off then this is less of a issue because you actually have to authorize, by signing the certificate, the client to connect to any puppet master/pool signed by the CA. On Fri, Feb 22, 2013 at 10:31 AM, Matthew Black <mjbl...@gmail.com> wrote: > I think you're missing what I'm trying to convey. When you run via > Apache or Nginx you are doing SSL termination at the apache and > forwarding the requests to a puppetmaster application if you use say > passenger. Its not so different than an F5. While I'm not giving you > exact details on how to do it I'm giving you enough information to > know its possible. > > The value of ca_server defaults to "puppet", that means the > certificate of the server it connects to must have that name in the > cert and the DNS must match. When you start up the first puppet > master, the CA server and not with mod_passenger, it will > auto-generate the CA cert because the value of ca defaults to true if > its not otherwise specified in the puppet conf. > > Essentially each puppet master that isnt the CA server is basically > just a puppet client meaning when it does its first run it will > generate a key, csr, and then try to connect to "puppet". You dont > actually need a cert for a puppet master if you do the ssl termination > at the load balancer. I provided a copy of my apache conf used for a > puppetmaster. As long as the puppetmasterd rack is installed it will > function as a puppetmaster with that config. > > You need to generate a signed certificate from the CA for the load > balancer dns. Lets say your DNS for one pool is > puppetpool01.example.com, that is the cert name you need to generate > and install on the apache/nginx load balancer. You need to also > configure the load balancer to validate the ssl cert from the client > against the CA. Specific parameters need to be passed to puppet, which > is specified in the apache conf below. In each puppet master that is > load balanced in its conf file in the master section you need to put > these two lines > > ssl_client_header = SSL_CLIENT_S_DN > ssl_client_verify_header = SSL_CLIENT_VERIFY > > You want to go the mod_passenger route then you can do ssl termination > otherwise to do the tcp proxy is a real pain in the ass (been there, > done that, never again). > > Below is an example of my apache conf where the communication is > unencrypted because of the ssl termination at the load balancer. > > As long as the cert on the load balancer is signed by the CA and you > set it up to pass the correct headers if the SSL cert is validated > against the CA then you do not need multiple CA's. > > That way this setup you can revoke a certificate from one place > instead of trying to figure out which CA you need to revoke it from. > In each of my datacenters I have at the very minimum two F5 VIPs that > go to 4 different puppet masters each with one common CA. I have at > the current moment 6 datacenters, meaning I have 25 puppetmasters (24 > servers, 1 CA). > > Hopefully this clarifies the point I am conveying. I know my apache > configs, specifically for mod_passenger, might need tweaking but this > actually works really good. Also if you pick up one of the puppet > books, I forget which one exactly, they actually tell you how do the > proxying with apache in a similar fashion to what I explained. > > ##### > Apache Conf > ##### > > Listen 18140 > > PassengerHighPerformance on > PassengerMaxPoolSize 12 > PassengerPoolIdleTime 30 > PassengerMaxRequests 10 > PassengerStatThrottleRate 120 > PassengerUseGlobalQueue on > RackAutoDetect On > RailsAutoDetect On > <VirtualHost *:18140> > ServerName ppm001.example.com > DocumentRoot /usr/share/puppet/rack/puppetmasterd/public/ > RackBaseURI / > <Directory /usr/share/puppet/rack/puppetmasterd/public/> > Options None > AllowOverride None > Order allow,deny > allow from all > </Directory> > SetEnvIf X-SSL-Subject "(.*)" SSL_CLIENT_S_DN=$1 > SetEnvIf X-Client-Verify "(.*)" SSL_CLIENT_VERIFY=$1 > SetEnvIf X-Forwarded-For "(.*)" REMOTE_ADDR=$1 > SetEnvIf X-Forwarded-Proto "https" HTTPS=1 > > LogLevel error > ErrorLog "|/usr/sbin/cronolog > /var/log/httpd/puppetmaster_error_log.%Y%m%d -l > /var/log/httpd/puppetmaster_error_log" > CustomLog "|/usr/sbin/cronolog > /var/log/httpd/puppetmaster_access_log.%Y%m%d -l > /var/log/httpd/puppetmaster_access_log" combined > </VirtualHost> > ##### > > On Thu, Feb 21, 2013 at 9:36 AM, <spankthes...@gmail.com> wrote: >> Dear Matt, >> >> >> On Wednesday, February 20, 2013 10:39:51 PM UTC, Matt wrote: >>> >>> I run an F5 load balancer with SSL termination at the F5 and I dont >>> need to put the CA cert anywhere except the F5. The actual CA signs >>> the certs. The CA cert is only really used to authenticate the client >>> cert. This gives the appearance to my puppet clients that I only have >>> one puppet master when in actuality I have around 4-5 per VIP. >> >> >> Unfortunately, I dont have F5 available and all I can have is software based >> load balancing, either in form of Haproxy (most probably) or Nginx (less >> probably). >> >>> >>> >>> As for your last part I'm not really seeing how you think you would >>> need a puppetmaster per user. >> >> >> As one puppetmaster can use one CA at a time to sign/revoke certificates, if >> you'd have multiple users, you would need multiple puppetmasters, to be sure >> that two (or more) users can use different CA's at the same time to >> sign/revoke their certs. Using openssl library and multiple instances of web >> app makes that possible, if using openssl to create CA's and >> signing/revoking certs is possible in first place. >> >>> >>> >>> On Wed, Feb 20, 2013 at 2:59 PM, <spankt...@gmail.com> wrote: >>> > Dear Matt, >>> > >>> > >>> > On Wednesday, February 20, 2013 5:41:11 PM UTC, Matt wrote: >>> >> >>> >> I think you're trying to over complicate the situation here. >>> >> >>> >> Yes its a single point of failure but unfortunately that is not going >>> >> to change anytime between now and maybe 6 months. >>> > >>> > >>> > I am aware of that, and I am fine with that. >>> > >>> >> >>> >> >>> >> You do not need multiple CAs to use multiple puppet masters. The >>> >> client needs to have the setting ca_server set to the Puppet Master >>> >> that is the CA. You need to configure that Puppet master with ca = >>> >> true. The puppet masters you create need to be configured with ca = >>> >> false. You can have 300 different puppet masters and each client can >>> >> connect to the different ones as needed. >>> > >>> > >>> > The thing is, the puppetmasters are exposed to puppet clients via >>> > loadbalancer, so they actually appear as one puppetmaster, therefore, >>> > they >>> > all need to have the same CA installed. >>> > >>> >> >>> >> >>> >> If you need to limit which clients can connect to which puppet masters >>> >> then you should look at the auth.conf file. >>> >> >>> >> As for a web interface around certificate signing, when each client >>> >> connects into the CA it will submit its request and if autosign is >>> >> turned off it should be setup to wait for certificate. The web >>> >> interface can be a wrapper around the puppet cert face so you can get >>> >> a list of certificates signed and whats waiting to be signed. You can >>> >> even set it up to revoke or clean out a certificate. You do not need >>> >> to call to the command line to do this either, you can interface with >>> >> the puppet api from rubygems. >>> > >>> > >>> > That, again, would require running puppetmaster per user, something I >>> > really, really want to avoid. >>> > >>> >> >>> >> >>> >> >>> >> On Tue, Feb 19, 2013 at 3:15 PM, <spankt...@gmail.com> wrote: >>> >> > Dear Felix, >>> >> > >>> >> > I think you're getting it wrong, let me clarify it a bit. The goal of >>> >> > this >>> >> > is to be able to write web interface for generating puppetmasters >>> >> > CA's >>> >> > and >>> >> > client certificates on demand. An example: install 3 puppetmasters >>> >> > with >>> >> > loadbalancer in front. Use web interface to generate CA and >>> >> > certificates >>> >> > for >>> >> > chosen clients (lets say, 10 machines). Deploy such generated CA's on >>> >> > puppetmasters, and relevant bits on puppet clients to authorize them >>> >> > against >>> >> > these puppetmasters. Whenever there's need for change, use that CA >>> >> > via >>> >> > web >>> >> > interface to add and delete client certificates, redeploy them on >>> >> > puppetmasters and so on. This, while doable via Subprocess functions >>> >> > (Python >>> >> > is the language of choice for me, but that doesnt really matters) and >>> >> > calls >>> >> > to relevant puppet system commands is extremely ugly and not flexible >>> >> > solution. I would love to do it via openssl library, but to do so, >>> >> > I'd >>> >> > need >>> >> > to have a workable way to build CA's and sign (and revoke) client >>> >> > certs >>> >> > via >>> >> > openssl command - so far I cant reach that goal. I hope this makes >>> >> > more >>> >> > sense now. >>> >> > >>> >> > Regards, >>> >> > S. >>> >> > >>> >> > On Tuesday, February 19, 2013 4:04:32 PM UTC, Felix.Frank wrote: >>> >> >> >>> >> >> On 02/16/2013 12:20 PM, spankt...@gmail.com wrote: >>> >> >> > after creating CA and client cert and applying them to >>> >> >> > puppetmaster, >>> >> >> > it >>> >> >> > complains with: >>> >> >> >>> >> >> Wait, what? You create a new CA, even after agents have already been >>> >> >> certified, then create new agent certificates? >>> >> >> >>> >> >> If your CA changes, you will have to terminate all the (now >>> >> >> deprecated) >>> >> >> agent certificates and sign new certificates for all agents. >>> >> >> >>> >> >> Basically, I would expect the outcome you are observing, and you >>> >> >> should >>> >> >> just follow the instructions given in your log excerpt. Note that >>> >> >> you >>> >> >> are *not* supposed to remove the CA from the master, only the copy >>> >> >> of >>> >> >> the agent's certificate. >>> >> >> >>> >> >> HTH, >>> >> >> Felix >>> >> > >>> >> > -- >>> >> > 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...@googlegroups.com. >>> >> > To post to this group, send email to puppet...@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...@googlegroups.com. >>> > To post to this group, send email to puppet...@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+unsubscr...@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+unsubscr...@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.
