Bug 1462670 - Octavia TripleO support: allow auto-generated or user-provided certificates when configuring octavia
Summary: Octavia TripleO support: allow auto-generated or user-provided certificates w...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-common
Version: 12.0 (Pike)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: beta
: 13.0 (Queens)
Assignee: Brent Eagles
QA Contact: Alexander Stafeyev
URL:
Whiteboard:
Depends On:
Blocks: 1433523 1433537
TreeView+ depends on / blocked
 
Reported: 2017-06-19 08:49 UTC by Nir Magnezi
Modified: 2019-09-10 14:08 UTC (History)
11 users (show)

Fixed In Version: openstack-tripleo-common-8.4.1-0.20180224032816.d51ed49.el7.centos
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-27 13:31:39 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
OpenStack gerrit 515402 None MERGED Octavia post deployment mistral wrapper 2020-09-03 02:50:40 UTC
Red Hat Product Errata RHEA-2018:2086 normal SHIPPED_LIVE Red Hat OpenStack Platform 13.0 Enhancement Advisory 2018-06-28 19:51:39 UTC

Description Nir Magnezi 2017-06-19 08:49:53 UTC
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 13:52:49 UTC
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 10:26:10 UTC
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 10:47:31 UTC
The fix has already landed the the puddle

Comment 32 errata-xmlrpc 2018-06-27 13:31:39 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:2086


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