Bug 1550934 - Openstack 12 - Missing mount in the keystone container
Summary: Openstack 12 - Missing mount in the keystone container
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 12.0 (Pike)
Hardware: x86_64
OS: Linux
Target Milestone: z3
: 12.0 (Pike)
Assignee: Emilien Macchi
QA Contact: Pavan
Depends On:
TreeView+ depends on / blocked
Reported: 2018-03-02 10:14 UTC by ojanas
Modified: 2018-08-20 12:59 UTC (History)
14 users (show)

Fixed In Version: openstack-tripleo-heat-templates-7.0.12-1.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-08-20 12:59:02 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:2331 None None None 2018-08-20 12:59:53 UTC
OpenStack gerrit 564107 None None None 2018-05-24 13:12:16 UTC

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:

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:


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.


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