Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
This commits adds the option to pass an internal certificate.
The aforementioned certificate will be used to terminate TLS
connections for the internal and admin endpoints.
Change-Id: I9d781b42c63cf34bd1f5ba2c71014c6b9de0f990
|
|
In order to reduce repeated code in the loadbalancer manifest, the
repeated parts were moved into one manifest that contains the
endpoint resource.
Change-Id: Ib72abe9de7ab073dcbd780298385b0c519f363aa
|
|
There were two issues with the SSL port for sahara.
* It was conflicting with Manila's port
* It was documented incorrectly
This has been fixed
Change-Id: I9f710e014890b6daa6b3e511fd811c1e25bd0de3
|
|
Change-Id: I7d2eb9405e0171fc54fa0b616122f69db5f51ce2
|
|
|
|
They are not being used and add extra logic and unnecessary clutter
to the code. So this CR removes them in favor of just configuring
TLS with the service_certificate. The only individual cert left was
the one for haproxy stats.
Change-Id: Ic3b769423917e723ecc83e32bcbae17568345661
|
|
AODH, Gnocchi, Sahara and Trove were missing from the service_ports
maps and thus had hardcoded ports in the listener configuration. The
addition of those ports to the map is required to give the
possibility to deployers to configure those ports if needed. This
commit adds them to that map.
Change-Id: Id009d65bf68ba91f97b0d60d32028da50fc88fc3
|
|
When managing the vip's, we were incorrectly comparing the vip to
$control_virtual_interface instead of $controller_virtual_ip when
determining if we needed to actually create the vip or not.
This caused the vips for internal api, storage, and storage mgmt to
always be created even if they were the same as the control vip. Afaict,
this didn't actually cause any problems, other than having extra vip's
created when they weren't needed. Still, this corrects the code to do
what it was intended to do.
Change-Id: I29aee95afcba25008b8b7bee37ba636eb2595cca
|
|
|
|
|
|
When accessing Redis, if password protected, we need to update
the HAProxy checks so that they use a password or we won't be able
to gather which node is the replica master.
Also adds PING/PONG and QUIT/OK sequence before and after the info
command is sent.
More at https://bugzilla.redhat.com/show_bug.cgi?id=1320036
Change-Id: Ia9e61e66c5426061eab8172f0a25820989597780
|
|
This CR enables the ability to set the cipher suite to be used by
HAproxy and the SSL options. So now the user can enable these through
hiera. The cipher suite comes from the Fedora system crypto policy.
Change-Id: Ia5751d4049026683fa13d4bc4cbf4eaffe054b48
Depends-On: I4943c6c74e0be96c1d7e190908b9262df05d059a
|
|
This adds a TLS binding listening on the internal network for
horizon. And on the other hand, if the public binding for horizon is
accessed via non-https, it will redirect to https.
Change-Id: I1f92ecd0c4845450df4b24f6b621d313ba9cbfc4
Depends-On: I4943c6c74e0be96c1d7e190908b9262df05d059a
|
|
Right now we always deploy the haproxy.stats endpoint with no
authentication, which is a security concern. Allow setting a
password on the endpoint so it isn't accessible to the world.
While this allows configuring SSL on the stats endpoint, it does
not use the service_certificate parameter because that certificate
is intended to be used only for public endpoints, and the stats
endpoint is actually on the admin VIP. Once we have support for
SSL on admin endpoints we can have stats use it by default.
Change-Id: I8a5844e89bd81a99d5101ab6bce7a8d79e069565
|
|
|
|
Some deployments were expecting specific ports for the OpenStack
services; In case the default ports are not meeting those needs, we
need to provide the means of changing the defaults.
Change-Id: Idbbcc90e2af1b3a731b0b5ea955df6082541a9f7
|
|
|
|
Heat has the ssl middleware to handle the X-Forwarded-Proto header by
default. We override this header when SSL is enabled because we need
to, but overriding it even when we won't be terminating SSL will
prevent some attacks using this header.
Change-Id: I0b2c61cd4f47c8c08a84402af310983af752d3f2
|
|
Current HAproxy config is broken for Redis timeout parameters. This is what we
have today by default in HAproxy logs:
[WARNING] 238/115010 (13878) : config : missing timeouts for proxy 'redis'.
| While not properly invalid, you will certainly encounter various problems
| with such a configuration. To fix this, please ensure that all following
| timeouts are set to a non-zero value: 'client', 'connect', 'server'.
This patch removes the explicit setting of client and server timeouts to 0,
which is the cause of the above warning. Instead, Redis will simply inherit the
haproxy defaults, which should be a more reasonable setting, and result in no
warnings.
Change-Id: Ibe7941bec02f5facf21732910c9ad96f547ff8e5
|
|
Right now, the only manipulation done to the X-Forwarded-Proto header
is done if an SSL connection is established. This is not sufficient as
one might be able to erroneously put values through that header.
This patch disables that behaviour by defaulting to plain http if an
SSL connection is not established.
Change-Id: I4bf6def21e21148834c2baa9669190bab8fa95ef
|
|
|
|
|
|
As for Heat, we need to be able to handle 30X redirects from Horizon
when configured to use SSL. Because Horizon's redirects are
handled directly by Apache, we can't use middleware to handle the
X-Forwarded-Proto header like we are planning to do for the other
services. However, in this case we don't need to worry about
rewriting urls in the payload like we do for the other services
because Horizon is just serving standard web pages, not custom
HTTP bodies with JSON contents.
One other change from the previous Heat patch is to drop the IP
from the rewrite regex. This is because Horizon will generally be
accessed via a DNS name, so the IP won't appear in the Location
header. The heat regex should probably be changed as well since
we now support registering endpoints with DNS names, but since we
plan to move all the other services to the X-Forwarded-Proto header
middleware anyway we can probably just wait until that happens and
then remove the Heat rule entirely.
Change-Id: I039a3036be17eeabe3cff68e0ef24f70907cc568
|
|
|
|
|
|
|
|
This is useful for handling URLs properly when TLS is enabled.
Change-Id: I4defed679cf3b2980dcc4ce1db030c0fdf154bfe
|
|
Change-Id: Ib57a4bf463900e68cbf97900027f972e590799c2
|
|
Change-Id: Iddf1fdaabc1c758546999e7af7e7412158400e7f
|
|
Change-Id: I3bd836140537fc5b7e3fba600a712d6a9d6f1185
|
|
Change-Id: Id5e119e0949d27a6e3b3f21ecd5e2eb39f1eeb13
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Haproxy is using session persistence[1] for horizon. It is not
correctly configured though. The cookie is not properly set. This add
the necessary code.
[1]: http://blog.haproxy.com/2012/03/29/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-know/
Change-Id: Ic9d79475cf84c25fb8146ecbc5f0a45862c106f0
Closes-Bug: 1526786
|
|
Adds configuration for Trove to loadbalancer class.
Partially-implements: blueprint trove-integration
Change-Id: I3cdf43b6d63ad0ee68db047518743c62b6689f56
|
|
Adds configuration for Sahara to loadbalancer class.
Change-Id: I0f0a1dc2eaa57d8226bad8cfb250110296ab9614
Partially-implements: blueprint sahara-integration
|
|
Change-Id: Icd666d9988d14ac1e9581f55589bf95243cc7641
|
|
|
|
MidoNet API needs to be loadbalanced if the midonet environment is
activated.
Change-Id: I6f1ac659297b8cf6671e11ad23284f8f543568b0
|
|
|
|
Change-Id: I3fdb705bbac26b4bc43a18131407a0a86d36a8a5
|
|
One of the ways to make use of TLS in keystone is through the usage of
the X-Fowarded-Proto header, which will be forwarded with the request
by the loadbalancer, and it will tell keystone what protocol was used
to access it. This also requires configuration from the keystone side.
Change-Id: I9b899ba95e28b7dfae0c1ed84ca8431054673925
|