Bug 1845091
Summary: | [osp16.1][update] New parameter required for 16.1 tls setup. | |||
---|---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Sofer Athlan-Guyot <sathlang> | |
Component: | documentation | Assignee: | Dan Macpherson <dmacpher> | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | RHOS Documentation Team <rhos-docs> | |
Severity: | urgent | Docs Contact: | ||
Priority: | urgent | |||
Version: | 16.1 (Train) | CC: | alee, amcleod, astillma, dmacpher, hrybacki, jpretori, ramishra, rheslop, sclewis, scohen, vcojot | |
Target Milestone: | rc | Keywords: | Triaged | |
Target Release: | 16.1 (Train on RHEL 8.2) | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Known Issue | ||
Doc Text: |
There is a known issue when you update from 16.0 to 16.1 with Public TLS or TLS-Everywhere.
+
The parameter `InternalTLSCAFile` provides the location of the CA cert bundle for the overcloud instance. Upgrades and updates fail if this parameter is not set correctly. With new deployments, heat sets this parameter correctly, but if you upgrade a deployment that uses old heat templates, then the defaults might not be correct.
+
Workaround: Set the `InternalTLSCAFile` parameter to an empty string `''` so that the undercloud uses the certificates in the default trust store.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1849703 (view as bug list) | Environment: | ||
Last Closed: | 2020-08-04 14:22:38 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: | 1840640 |
Description
Sofer Athlan-Guyot
2020-06-08 13:00:03 UTC
Changing ownership to DFG:Security so that they can explain correctly when and how the user should change add the new parameter and setting it to empty. Probably best to make ownership both Security and Upgrade. I'll most likely be working on it. So essentially, we just need to document the need for InternalTLSCAFile when doing a 16.0 to 16.1 update. Sounds fine to me. However, would this also affect upgrades too e.g. 13->16.1? Also if I understand correctly, the main reason for the inclusion of the new param is because we used it for the undercloud only in 16.0, and now we're using this param for both the undercloud and overcloud? Hey dan, so the context of when exactly you need to include that should be provided by security (got a call with them and it may depends on the tls setup). Now why do we need it is because the way security parameter is done/passed down in 16.1. So we need to adjust from 16.0 and certainly from 13.0 even if we should check that in CI as well. But again, I can test it part of it (basically what infrared gives me), but I don't have the detailed answer. Dan, During the install process, some default users, projects and groups are created on the overcloud. These used to be executed on the controllers, but this had the unfortunate effect of requiring credentials to be added to the controllers. Instead, in 16.1, this operation was moved to the undercloud. The parameter InternalTLSCAFile provides the location of the CA cert bundle for the overcloud instance. The above operation will fail if this parameter is not set correctly. This is not an issue for new deployments because the the THT templates do set this parameter as needed. But if a customer tries to do an upgrade using old templates, then the defaults may not be correct. On new deployments, the parameter is typically set in one of two templates: environments/ssl/enable-tls.yaml environments/ssl/enable-internal-tls.j2.yaml The first template is typically used when a cert is provided to the deployment for the public interfaces. The second template is used when deploying tls-everywhere -- tls interfaces on both public and private interfaces. For upgrades, therefore, the guidance is as follows: -- If your deployment is using public TLS - ie. TLS on the public interfaces only, then you must have added the required cert to the deployment somewhere and trusted it in the default trust store. The easiest solution here is to set this parameter to '' (empty string). This has the effect of telling the undercloud to use the certificates in the default trust store. -- If your deployment is using TLS-Everywhere and your public certs are being issued by IPA, then the parameter should be set to /etc/ipa/ca.crt. Actually -- in this case -- given that the IPA CA cert should already be in the default trust store -- it should be OK to use '' in this case too. Leaving for Rabi to comment on this. This parameter should be set prior to upgrade or the above keystone operations on the underclouds will fail. This is going to be required for any upgrade/update to 16.1. Rabi, does this match your understanding of things? *** Bug 1849703 has been marked as a duplicate of this bug. *** Stealing this BZ so I can include this information in the update and upgrade guides. Hi Dan, what is the current state of that bugzilla. It looks "solved" to me, so I'm wondering what is needed to close it ? Thanks, Correct. This has been implemented: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/keeping_red_hat_openstack_platform_updated/preparing-for-a-minor-update#updating-your-tls-ssl-configuration BZ is safe to close. |