Bug 1462670 - Octavia TripleO support: allow auto-generated or user-provided certificates when configuring octavia
Octavia TripleO support: allow auto-generated or user-provided certificates w...
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-common (Show other bugs)
12.0 (Pike)
Unspecified Unspecified
high Severity high
: beta
: 13.0 (Queens)
Assigned To: Brent Eagles
Alexander Stafeyev
: Triaged
Depends On:
Blocks: 1433523 1433537
  Show dependency treegraph
Reported: 2017-06-19 04:49 EDT by Nir Magnezi
Modified: 2018-04-17 14:42 EDT (History)
12 users (show)

See Also:
Fixed In Version: openstack-tripleo-common-8.4.1-0.20180224032816.d51ed49.el7.centos
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenStack gerrit 515402 None master: MERGED tripleo-common: Octavia post deployment mistral wrapper (If07ded033be9f44b7c7a7e09214032fa89a02e77) 2018-03-21 09:48 EDT

  None (edit)
Description Nir Magnezi 2017-06-19 04:49:53 EDT
Description of problem:
Octavia provides a script for generating certificates, as mentioned here[1], but I'm not sure this is what we expect our customers to do.
Moreover, we currently exclude[2] this script from our packaging, so we don't even currently ship it.

The end result we aim to achieve here is to have a tripleO doc (which is WIP[3]) that guides the operator on how exactly he/she should deploy Octavia. As currently some steps are executed manually.

The certificates part is currently expected to be executed before[3] the deployment even starts, yet it is not clear how/what we expect the operator to do and what is the best practice for secure certificate configuration.

To the best of my knowledge, we have two alternatives here:
1. Use the solution mentioned in https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/tls_everywhere.html
2. Use and ship the Octavia certificates creation script: https://github.com/openstack/octavia/blob/master/bin/create_certificates.sh

[1] https://docs.openstack.org/developer/octavia/guides/dev-quick-start.html#create-octavia-keys-and-certificates
[2] https://github.com/rdo-packages/octavia-distgit/blob/rpm-master/openstack-octavia.spec#L336
[3] https://review.openstack.org/#/c/447496/20/doc/source/advanced_deployment/octavia-post-deploy.sh@263
Comment 1 Brent Eagles 2017-10-26 09:52:49 EDT
It's not clear that the spirit of "TLS everywhere" is compatible with "as a service" components like octavia and likely warrants a larger conversation including storage and anyone seeking to integrate other "as a service" components.

The original intent of this bug was to find out the proper way to integrate cert generation into the deployment. I'm updating the title of the bug accordingly.
Comment 10 Or Idgar 2017-12-27 05:26:10 EST
We are now in a middle of discussion about how to generate or import the certificate.

For user-provided certificate, we have already a solution by copying the certificate content into an environment file.

For auto-generated certificate, we should see if TLS Everywhere can somehow intergate with Octavia and if it's the right thing to do, as this should lead to additional manual steps before deploying the overcloud (such as create manually CA files or install FreeIPA server) + all other TLS/SSL supported services will enable encrypted socket.
Up to now we generated self-signed certificates by using OpenSSL CLI.
Comment 28 Nir Magnezi 2018-04-16 06:47:31 EDT
The fix has already landed the the puddle

Note You need to log in before you can comment on or make changes to this bug.