Tweak HAProxy spec to deal with mixed services.
Turns out we didn't dig deep enough when designing it. Change-Id: I144e627465d4a28ad692c14c03c1ec6387ef1f86
This commit is contained in:
parent
09f124d79a
commit
2cc5b31b54
@ -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,
|
* the non-ssl endpoint is reachable from outside the local host,
|
||||||
which could potentially confuse users and expose them to an insecure connection
|
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
|
Proposed Change
|
||||||
===============
|
===============
|
||||||
|
|
||||||
The most convenient setup in my opinion, and also fits nicely in current code
|
We will bind haproxy, stunnel (ssl), openstack services on ports with
|
||||||
(requires minor refactoring), is to bind haproxy, stunnel (ssl), openstack services
|
different ipaddress settings.
|
||||||
on same 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
|
vip_address = 192.0.2.21
|
||||||
node_address = 192.0.2.24
|
node_address = 192.0.2.24
|
||||||
|
|
||||||
1. haproxy
|
1. haproxy
|
||||||
|
listen horizon_http
|
||||||
bind vip_address:80
|
bind vip_address:80
|
||||||
bind vip_address:443
|
|
||||||
|
|
||||||
listen horizon
|
|
||||||
server node_1 node_address:80
|
server node_1 node_address:80
|
||||||
|
listen horizon_https
|
||||||
|
bind vip_address:443
|
||||||
|
server node_1 node_address:443
|
||||||
|
|
||||||
2. stunnel
|
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
|
connect 127.0.0.1:80
|
||||||
|
|
||||||
3. horizon
|
3. horizon
|
||||||
bind 127.0.0.1:80
|
bind 127.0.0.1:80
|
||||||
|
|
||||||
|
|
||||||
Alternatives
|
Alternatives
|
||||||
------------
|
------------
|
||||||
|
|
||||||
@ -106,7 +134,7 @@ Option 3: Add additional ssl termination before load-balancer
|
|||||||
Security Impact
|
Security Impact
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
* Only ssl protected endpoints are publicly available
|
* Only ssl protected endpoints are publicly available if running SSL only.
|
||||||
* Minimal firewall configuration
|
* Minimal firewall configuration
|
||||||
* Not forwarding decrypted traffic over non-localhost connections
|
* Not forwarding decrypted traffic over non-localhost connections
|
||||||
* compromise of a control node exposes all external traffic (future and possibly past)
|
* compromise of a control node exposes all external traffic (future and possibly past)
|
||||||
@ -135,6 +163,16 @@ None
|
|||||||
Implementation
|
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)
|
Assignee(s)
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
@ -152,7 +190,7 @@ tripleo-image-elements:
|
|||||||
|
|
||||||
* openstack-ssl element refactoring
|
* 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,
|
horizon apache configuration, glance, nova, cinder, swift, ceilometer,
|
||||||
neutron, heat, keystone, trove
|
neutron, heat, keystone, trove
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user