Hi Neil,
Thanks for sharing that config, it's quite useful.
Did you see any large benefit of this versus using DNS SRV records (yes, I
understand the actual load balancing implications).
I'm curious if the extra infrastructure was worth the effort.
I'm partial to a fan-out DNS SRV structure, but that doesn't really help
with load unless your servers are active rejecting above a given connection
load.
Thanks,
Trevor
On Mon, Sep 19, 2016 at 5:09 AM, Neil - Puppet List <
maillist-pup...@iamafreeman.com> wrote:
> Hello
>
> One extra thing to mention is I have got into issues with configuring the
> loadbal itself through puppet, as broken loadbal config breaks the puppet
> service which means the loadbal can;t be fixed via puppet, so admin login
> is required on these servers.
>
> Thanks
>
> Neil
>
> On 19 September 2016 at 10:07, Neil - Puppet List <
> maillist-pup...@iamafreeman.com> wrote:
>
>> Hello
>>
>> Below is a slightly edited version of the haproxy.cfg
>>
>> All the backends except the ca require a valid client cert 'http-request
>> deny unless { ssl_c_verify 0 }'
>>
>> global
>> chroot /var/lib/haproxy
>> daemon
>> group haproxy
>> log 127.0.0.1 local4
>> log 127.0.0.1 local5 notice
>> maxconn 20000
>> pidfile /var/run/haproxy.pid
>> stats socket /var/run/haproxy.stat mode 600
>> tune.ssl.default-dh-param 2048
>> user haproxy
>>
>> defaults
>> log global
>> maxconn 20000
>> option redispatch
>> retries 3
>> timeout http-request 10s
>> timeout queue 1m
>> timeout connect 10s
>> timeout client 1m
>> timeout server 1m
>> timeout check 10s
>>
>> frontend hastats
>> bind 0.0.0.0:443 ssl no-sslv3 crt /etc/ssl/private/puppet.lse.ac.uk.pem
>> no-sslv3 ciphers ECDHE-RSA-AES128-GCM-SHA256:EC
>> DHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDH
>> E-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-
>> AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-
>> ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-
>> SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:
>> ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-
>> AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-
>> RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:
>> AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:AES:DES-
>> CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK
>> default_backend ibe_hastats
>> mode http
>> option httplog
>> rspadd Strict-Transport-Security:\ max-age=31536000
>>
>> frontend puppet
>> bind 0.0.0.0:8140 ssl no-sslv3 crt /etc/ssl/private/puppet.lse.ac.uk.pem
>> ca-file /etc/haproxy/ca_crt.pem verify optional crl-file
>> /etc/haproxy/ca_crl.pem ciphers ECDHE-RSA-AES128-GCM-SHA256:EC
>> DHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDH
>> E-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-
>> AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-
>> ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-
>> SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:
>> ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-
>> AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-
>> RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:
>> AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:AES:DES-
>> CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK
>> acl use_ca path_reg ^/[a-z0-9\-\.]*/certificate/
>> acl use_ca path_reg ^/[a-z0-9\-\.]*/certificate_request/
>> acl use_dev ssl_c_s_dn(cn) -m sub -- -dev
>> acl use_foreman ssl_c_s_dn(cn) -m beg testforemanclient
>> acl environment_production path_beg /production/catalog
>> default_backend be_puppet_stable
>> http-request set-header X-SSL %[ssl_fc]
>> http-request set-header X-SSL-Client-Verify %[ssl_c_verify]
>> http-request set-header X-SSL-Client-SHA1 %{+Q}[ssl_c_sha1]
>> http-request set-header X-SSL-Client-DN %{+Q}[ssl_c_s_dn]
>> http-request set-header X-SSL-Client-CN %{+Q}[ssl_c_s_dn(cn)]
>> http-request set-header X-SSL-Issuer %{+Q}[ssl_c_i_dn]
>> http-request set-header X-SSL-Client-Not-Before %{+Q}[ssl_c_notbefore]
>> http-request set-header X-SSL-Client-Not-After %{+Q}[ssl_c_notafter]
>> mode http
>> option forwardfor
>> option httplog
>> use_backend be_puppet_ca if use_ca
>> use_backend be_puppet_dev if use_dev
>> use_backend be_puppet_foreman if use_foreman
>>
>> backend be_puppet_ca
>> mode http
>> server sys-puppet-ca-prod-0 sys-puppet-ca-prod-0:8140 check inter 15s
>> rise 2 fall 2
>>
>> backend be_puppet_dev
>> balance source
>> hash-type map-based
>> http-request deny unless { ssl_c_verify 0 }
>> mode http
>> server sys-puppet-app-prod-0 sys-puppet-app-prod-0:8140 check inter
>> 15s rise 2 fall 2
>>
>> backend be_puppet_foreman
>> balance source
>> hash-type map-based
>> http-request deny unless { ssl_c_verify 0 }
>> mode http
>> server sys-puppet-app-prod-1 sys-puppet-app-prod-1:8140 check inter
>> 15s rise 2 fall 2
>>
>> backend be_puppet_stable
>> balance source
>> hash-type map-based
>> http-request deny unless { ssl_c_verify 0 }
>> mode http
>> server sys-puppet-app-prod-2 sys-puppet-app-prod-2:8140 check inter
>> 15s rise 2 fall 2
>>
>> backend ibe_hastats
>> mode http
>> stats uri /hastats/
>> stats realm HAStatistics
>> stats auth admin:PASSWORDFORADMINACCESSTOSTATSPAGE
>> stats admin if TRUE
>>
>> On 18 September 2016 at 09:10, Gareth Rushgrove <gar...@morethanseven.net
>> > wrote:
>>
>>> On 17 September 2016 at 15:06, Neil - Puppet List
>>> <maillist-pup...@iamafreeman.com> wrote:
>>> > Hello
>>> >
>>> > I've run multiple puppet masters behind ha proxy for a few years now.
>>> I have
>>> > multiple masters, with haproxy rules directing some clients to
>>> particular
>>> > masters. I only have one puppet master as CA. I've about 600 clients.
>>> >
>>> > Initially I was concerned about only having one CA. But all it does is
>>> sign
>>> > new clients and revoke old. Haproxy trusts the clients based on this
>>> CA and
>>> > a revoke list from the CA.
>>> >
>>> > If the CA went down all existing clients would are fine, I've tested
>>> that. I
>>> > can't sign new clients or revoke existing until I recover the CA but
>>> in my
>>> > environment that's no big deal. I have backups of the CA and a new one
>>> would
>>> > not take long to spin up.
>>> >
>>> > So I wonder why you want multiple CA. What benefits would it bring?
>>> >
>>> > Happy to share example haproxy config etc if you are interested.
>>> >
>>>
>>> I'd certainly be interested in the example if you don't mind.
>>>
>>> Gareth
>>>
>>> > Cheers,
>>> >
>>> > Neil
>>> >
>>> >
>>> > On 12 Sep 2016 16:07, "Peter Kristolaitis" <alte...@alter3d.ca> wrote:
>>> >>
>>> >> Serial numbers on SSL certificates are important, and your setup will
>>> >> generate many duplicate serial numbers. Ergo, this is bad.
>>> >>
>>> >> Related problem: Did you test revoking a client certificate? I
>>> suspect
>>> >> not, because the above issue will bite you.
>>> >>
>>> >>
>>> >> On 2016-09-12 12:48 AM, Ivan Arjune wrote:
>>> >>
>>> >> Did i figure out something new here, because I've been digging at
>>> this for
>>> >> a week and don't see anyone doing it like this.
>>> >>
>>> >> What i'm doing is running multiple puppetmasters behind haproxy. Each
>>> >> puppetmaster is an active ca server and share a common certificate.
>>> It
>>> >> works like a charm, in a lab.
>>> >>
>>> >> Step 1. created a common certificate that all the puppetservers will
>>> >> share.
>>> >> Step 2. point webserver.conf to the shared certs.
>>> >> Not a step 3. hit the masters through haproxy
>>> >>
>>> >> I posted this up on ask.puppet.com a few days ago and nobody seems
>>> >> interest in it. Either it's a stale forum, which i believe is true,
>>> or they
>>> >> think i'm crazy. Maybe you do to, ugg....
>>> >>
>>> >> Here is the orig. post with details on the setup.
>>> >> Puppet CA Shared Certificate Guide: Scalable Puppet?
>>> >>
>>> >> I'm looking to put this into production on an infra. with around 200
>>> >> nodes. I think it's a good idea, but can't figure out why I don't see
>>> >> anyone doing it like this yet.
>>> >>
>>> >> Million dollar question:
>>> >> Why must i use a centralized the ca server?
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> 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/6dcd4a20-909c
>>> -4373-892f-0f7a3e69d19d%40googlegroups.com.
>>> >> For more options, visit https://groups.google.com/d/optout.
>>> >>
>>> >>
>>> >> --
>>> >> 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/c5dbbb59-4de7
>>> -720f-3424-3135db424522%40alter3d.ca.
>>> >> For more options, visit https://groups.google.com/d/optout.
>>> >
>>> > --
>>> > 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/CAAohVBfGJx14
>>> uUqocAXPw7oJvBdVsenQhE4rjDSNCXCwjM94Vg%40mail.gmail.com.
>>> >
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>> --
>>> Gareth Rushgrove
>>> @garethr
>>>
>>> devopsweekly.com
>>> morethanseven.net
>>> garethrushgrove.com
>>>
>>> --
>>> 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/ms
>>> gid/puppet-users/CAFi_6yLdmbE9QZ2%2BZ-OpuFGyt-mNRF5n2NuQ21SF
>>> iNTyTEbA0g%40mail.gmail.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
> --
> 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/CAAohVBfC-E%2BXp5_td2j0n9EW4rcKPcx47kxYJ4tT8sjpN
> %3DSBkw%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAAohVBfC-E%2BXp5_td2j0n9EW4rcKPcx47kxYJ4tT8sjpN%3DSBkw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
--
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/CANs%2BFoX3jnRD6O%2BNUKNyrmiN9vMeQNt986oeV6DqRCxGoS9uNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
