Bug 1462670

Summary:	Octavia TripleO support: allow auto-generated or user-provided certificates when configuring octavia
Product:	Red Hat OpenStack	Reporter:	Nir Magnezi <nmagnezi>
Component:	openstack-tripleo-common	Assignee:	Brent Eagles <beagles>
Status:	CLOSED ERRATA	QA Contact:	Alexander Stafeyev <astafeye>
Severity:	high	Docs Contact:
Priority:	high
Version:	12.0 (Pike)	CC:	amuller, astafeye, beagles, cgoncalves, jjoyce, jlibosva, mburns, nyechiel, rhel-osp-director-maint, sclewis, slinaber
Target Milestone:	beta	Keywords:	Triaged
Target Release:	13.0 (Queens)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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:		Environment:
Last Closed:	2018-06-27 13:31:39 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1433523, 1433537

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