Bug 1550934

Summary:	Openstack 12 - Missing mount in the keystone container
Product:	Red Hat OpenStack	Reporter:	ojanas
Component:	openstack-tripleo-heat-templates	Assignee:	Emilien Macchi <emacchi>
Status:	CLOSED ERRATA	QA Contact:	Pavan <pkesavar>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	12.0 (Pike)	CC:	dbecker, ealcaniz, emacchi, hrybacki, jdennis, josorior, kbasil, mburns, mlehmann, morazi, nkinder, rhel-osp-director-maint, slinaber, srevivo
Target Milestone:	z3	Keywords:	Triaged, ZStream
Target Release:	12.0 (Pike)
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	openstack-tripleo-heat-templates-7.0.12-1.el7ost	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-08-20 12:59:02 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:

Description ojanas 2018-03-02 10:14:15 UTC

Description of problem:

Customer is trying to configure Active Directory as an Idm in keystone.

According to the documentation at:
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/12/html/integrate_with_identity_service/sec-active-directory#configure_the_ldaps_certificate

there is one part doing:
# cp addc.lab.local.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust

The problem is that the host path /etc/pki/ca-trust/source/anchors is not mounted into the keystone container so the certificate, obviously, can not be found inside the container.

The workaround is to manually copy the certificate into the container.

The solution seems to be simple, just add another mount into the container if there is no conflict.

How reproducible:

Run this on OSP 12 controller node:

docker inspect -f '{{.Mounts}}' <ID of keystone container>

From the output you can see the appropriate mount is missing.

Actual results:
There is a missing mount in the keystone container.

Expected results:
The mount is not missing inside the keystone container

Comment 1 John Dennis 2018-03-19 16:08:33 UTC

FWIW, it's not just the /etc/pki/catrust/source/anchors that's needed, but also /etc/pki/tls/certs because that's where the update-ca-trust writes what is in source/anchors and where the TLS libraries read the set of trusted CA's.

Comment 2 Juan Antonio Osorio 2018-03-19 16:12:12 UTC

These are mounted already:

"/etc/pki/ca-trust/extracted:/etc/pki/ca-trust/extracted:ro",
"/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/ca-bundle.trust.crt:ro",
"/etc/pki/tls/cert.pem:/etc/pki/tls/cert.pem:ro",
"/etc/pki/tls/certs/ca-bundle.crt:/etc/pki/tls/certs/ca-bundle.crt:ro"

Comment 3 John Dennis 2018-03-21 18:58:55 UTC

After reviewing the documentation in listed in the original bug report it would appear there is an erroneous step listed. We believe (but have not yet confirmed via testing) there is no need to add the AD CA cert to the hosts system trust via update-ca-trust (which reads it from /etc/pki/catrust/source/anchors. There are two reasons for this conclusion.

1) The document was not written with containers in mind. As a general rule a container running on a host should not modify or have the ability to modify the hosts security profile. By giving a container write access to /etc/pki/catrust/source/anchors the container is able to inject any CA cert into the host systems trust profile. Providing a read-only mount in the container is nonsensical because /etc/pki/catrust/source/anchors is where you *write* CA certs that will then be added by update-ca-trust.

2) Keystone's LDAP implementation does not utilize the CA trust of the system irregardless of whether Keystone is running natively on the host or inside a container running on the host. Rather the CA cert used by Keystone's LDAPS is a file or directory specified by either the tls_cacertfile or tls_cacertdir Keystone configuration parameters.

I communicated with the original doc writer and asked if he recalled any reason why the AD CA cert needed to be added to the system trust instead of just pointing Keystone to the AD CA cert. He couldn't remember any reason and though maybe he added that to support testing with the ldapsearch command line tool.

Thus 3 things need to happen:

1) We should verify there is no need for the AD CA cert to be added to the system trust.

2) Assuming the above is verified we need to update the doc.

3) We still need a mechanism to have the AD CA cert be visible in the container so that Keystone can reference the file specified in the tls_cacertfile. I need to coordinate more with Ozz (e.g. Juan) to determine the best mechanism for this. We've already outlined a few ideas.

Comment 20 errata-xmlrpc 2018-08-20 12:59:02 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/RHSA-2018:2331