From 2cc5b31b545f3d7e52264e2e203a110c755645b0 Mon Sep 17 00:00:00 2001 From: Robert Collins Date: Fri, 18 Jul 2014 22:18:10 +1200 Subject: [PATCH] Tweak HAProxy spec to deal with mixed services. Turns out we didn't dig deep enough when designing it. Change-Id: I144e627465d4a28ad692c14c03c1ec6387ef1f86 --- specs/juno/haproxy_configuration.rst | 62 ++++++++++++++++++++++------ 1 file changed, 50 insertions(+), 12 deletions(-) diff --git a/specs/juno/haproxy_configuration.rst b/specs/juno/haproxy_configuration.rst index ae5510cb..a088e681 100644 --- a/specs/juno/haproxy_configuration.rst +++ b/specs/juno/haproxy_configuration.rst @@ -29,35 +29,63 @@ This configuration has some drawbacks and wont work in ha, for several reasons: * the non-ssl endpoint is reachable from outside the local host, which could potentially confuse users and expose them to an insecure connection - + in the case where we want to run that service on SSL only. We want to offer SSL + by default but we can't really prevent it. Proposed Change =============== -The most convenient setup in my opinion, and also fits nicely in current code -(requires minor refactoring), is to bind haproxy, stunnel (ssl), openstack services -on same ports with different ipaddress settings. +We will bind haproxy, stunnel (ssl), openstack services on ports with +different ipaddress settings. -In case of using stunnel: +HAProxy will be bound to VIP addresses only. + +STunnel where it is used will be bound to the controller ctlplane address. + +OpenStack services will bind to localhost for SSL only configurations, and to +the ctlplane address for non-SSL or mixed-mode configurations. They will bind +to the standard non-encrypted ports, but will never bind to 0.0.0.0 on any +port. + +We'll strive to make SSL-only the default. + +An example, using horizon in mixed mode (HTTPS and HTTP): vip_address = 192.0.2.21 node_address = 192.0.2.24 1. haproxy + listen horizon_http bind vip_address:80 - bind vip_address:443 - - listen horizon server node_1 node_address:80 + listen horizon_https + bind vip_address:443 + server node_1 node_address:443 2. stunnel - accept node_address:80 + accept node_address:443 + connect node_address:80 + +3. horizon + bind node_address:80 + +A second example, using horizon in HTTPS only mode: + +vip_address = 192.0.2.21 +node_address = 192.0.2.24 + +1. haproxy + listen horizon_https + bind vip_address:443 + server node_1 node_address:443 + +2. stunnel + accept node_address:443 connect 127.0.0.1:80 3. horizon bind 127.0.0.1:80 - Alternatives ------------ @@ -106,7 +134,7 @@ Option 3: Add additional ssl termination before load-balancer Security Impact --------------- -* Only ssl protected endpoints are publicly available +* Only ssl protected endpoints are publicly available if running SSL only. * Minimal firewall configuration * Not forwarding decrypted traffic over non-localhost connections * compromise of a control node exposes all external traffic (future and possibly past) @@ -135,6 +163,16 @@ None Implementation ============== +We need to make the service configs - nova etc - know on a per service basis +where to bind. The current approach uses logic in the template to choose +between localhost and my_ip. If we move the selection into Heat this can +become a lot simpler (read a bind address, if set use it, if not don't). + +We considered extending the connect_ip concept to be on a per service basis. +Right now all services are exposed to both SSL and plain, so this would be +workable until we get a situation where only some services are plain - but we +expect that sooner rather than later. + Assignee(s) ----------- @@ -152,7 +190,7 @@ tripleo-image-elements: * openstack-ssl element refactoring -* refactor services configs to listen on 127.0.0.1: +* refactor services configs to listen on 127.0.0.1 / ctlplane address: horizon apache configuration, glance, nova, cinder, swift, ceilometer, neutron, heat, keystone, trove