Setting up Keberos for Keystone auth with mod_auth_gssapi
I’ve been following blog posts about setting up Keystone with kerberos authentication, and recently tried to implement that manually in TripleO. Here’s how it went:
mod_auth_gssapi instead of mod_auth_kerb
Asking around, it turns out that mod_auth_kerb is not going to be supported anymore, and using mod_auth_gssapi is the preferred alternative. Unfortunately all the blogs I found were using mod_auth_kerb, so I needed to research how to use mod_auth_gssapi.
We’ll need to install the following packages in the host where keystone is running:
Given that we run keystone in a container in TripleO, I needed to add those packages to the keystone container.
This would leave me with a deployment where I can authenticate to keystone using users coming from FreeIPA’s LDAP.
Given that we deployed using TLS everywhere, we already have quite a bunch of
service principals registered in FreeIPA, namely, we already have
HTTP/overcloud-controller-<number>.<networks>.<domain>. Unfortunately, this
is not a principal we can use, since the clients will authenticate to keystone
by first going through HAProxy, which is listening on the external network and
has the FQDN that references the ‘cloud name’. Lets say that our domain is
example.com. In that case, we’ll need to have a principal that looks as
HTTP/overcloud.example.com@EXAMPLE.COM (assuming our kerberos
realm matches the domain).
So, lets add this principal to FreeIPA:
Subsequently, we’ll need to tell FreeIPA that the service is being managed by
another host (given that there actually isn’t a host for
overcloud.example.com). Assuming we only have one controller named
overcloud-controller-0.example.com, we can make it manage the service with
the following command:
Having done this in the FreeIPA server, we can now go to our controller(s) and get the necessary kerberos keytab for that service:
We’ll notice that I used
a path. This is because we’re using a containerized deployment in TripleO, and
this is the directory that’s bind-mounted to the keystone container.
I also changed the file permissions of the keytab, so the apache process can access it.
With all the previous steps done, we can start configuring keystone’s apache instance!
To avoid issues in the container, I manually copied
conf.modules.d directory. We can do this from the host by
getting that file as
Subsequently, I added the following configuration to keystone’s apache
configuration in the
We’ll be able to modify this file from the host by editing
Something similar will need to be done for the admin endpoint, which is in the
same directory as
We’ll note that the
WSGIScriptAlias / ... and
already existed in the configuration.
It is also very relevant that the
/krb route is added before the
else we’ll get 404 errors in our deployment.
Finally, I changed the
methods configuration option that’s under the
With this, we can now restart the keystone container:
Note that we’ll need the package
python-requests-kerberos in the client side
To test this out, I created a user called ‘demo’ and a project called ‘freeipa-project’ in the LDAP-backed domain called ‘freeoipadomain’.
We need to authenticate to kerberos using the desired principal:
We’ll also need an rc file. For this example, it’ll look as follows:
Lets try it out!
Rob Crittenden sat down with me (virtually) to try to get this working. Thanks dude!