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
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.
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"
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.
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