RFC: Using Foreman client certificates for all backend service communication

ehelms · April 30, 2021, 6:52pm

This RFC can be thought of as a subset of the larger Certificates RFC.

The effort here is being tracked with this Redmine: Tracker #32381: Communication with services from Foreman application should use a single set of client certificates - Installer - Foreman and you can find links to the PRs for the details.

Goal

The goal of this RFC is to move from a model of generating client certificates per service that we communicate with to using the Foreman client certificates for all communication. This reduces the need to generate and manage multiple special use certificates simplifying deployments, understanding and overhead.

Details

Candlepin Artemis

A set of dedicated client certificates are generated to communicate with the Artemis service running inside Candlepin. There is RBAC present that restricts access based upon the DN presented with the certificate and is required to be in a specific format. Moving to using the Foreman client certificates primarily revolves around being able to to more dynamically derive the the DN based on the certificate to pass along to the configuration (Refs #32381: Add function to determine the Artemis user string dynamically from th… by ehelms · Pull Request #405 · theforeman/puppet-katello · GitHub).

Pulp 3 API

Pulp 3 API authentication revolves around setting the REMOTE_USER header in Apache and passing that along to the pulpcore-api.service. This header is set based on the CN of the certificate presented. Thus, today we generate a set of dedicated client certificates with a CN of admin. To move to Foreman client certificates, Apache can set the header based on if the certificates CN matches a defined value. Thus we need only to declare what CN to match against. This can be seen with initial work here.

Other services?

I am admittedly most familiar with Pulp and Candlepin and how we build the certificate structure for those services. If there are instances within the community that fit this model that could use work to move to this model please respond to this thread with details and I’ll take a look.

ekohl · May 5, 2021, 8:48am

To me the goal is to minimize the number of files that the Foreman user needs to connect. So using the same client certificates for all outgoing connections is a good start. Then we also have the CA files that we use to verify connections.

I started a PR to Katello core, but haven’t had time to finish it.

github.com/Katello/katello

Fixes #30368 - Make Candlepin CA file optional

Katello:master ← ekohl:candlepin-use-ca-file

opened 06:59PM - 10 Jul 20 UTC

ekohl

+15 -20

This change makes the Candlepin CA file optional by falling back to the Foreman …CA file. The result is a reduced configuration in most deployments. For Pulp the certificate is now read in the same way as Candlepin. Previously it partly relied on the CA being in the global allowed CA. This may be an issue in some cases, but in the default deployment it isn't. Following the general SSL config makes the configuration more predictable for users. It can also be easier in a containerized setup or on a system where the admin is not allowed to modify the system CA certificates. The example config is now also consistent with reality. The verify_ssl option is dropped from the ping model. This isn't respected elsewhere and it's misleading to have a valid ping only to have it fail at runtime.

During that PR I realized that the connection to Pulp can use a different CA file and we don’t have that. However, there is a more generic need for it and this PR would add a setting for it:

https://github.com/theforeman/foreman/pull/8076

That CA is exactly the one that Pulp is on since it’s in the same vhost. For remote Smart Proxies I think we have the constraint that it should be signed by the same CA.

Once it’s merged, we need to modify the installer to set it:

https://github.com/theforeman/puppet-foreman/pull/910

Do you agree that we should include it in the scope?

ehelms · May 21, 2024, 10:04pm

This RFC was completed a while ago - so I am marking it as such.