tldr: Katello supports one cert as of today. If we want to add a dropdown to select debug cert algorithm type. Do we feature flag til dual cert support is added or just display the dropdown but only give the user one option to chose from.
Context and Problem Statement
With Candlepin 4.8+ supporting PQC algorithms for debug certs. Candlepin currently has a hard coded map of the OID’s it supports (RSA, ml-dsa). I have opened up a PR that will support sending these algorithm certs from the Katello side. The PR is currently opened here[1].
After some discussion it may be good to create an RFC for this, overall not much changes API wise, we now get two extra query params by the name key_algorithms and signature_algorithms. These are then sent to Candlepin. Katello simply returns the result that Candlepin gives us. For API user’s I expect Katello to accept whatever OID strings, even if they are garbage and wrong since Candlepin is the “source of truth” here.
Proposal
For users that use the UI we plan to create a dropdown next to the generate debug cert button. Currently there are two ways we are thinking of going about the UI portion. The downside is Katello supports one cert as of today with plans of supporting dual certs. Should we feature flag the dropdown since Katello only supports one cert as of today, or should we keep the dropdown visible to users but pre-fill, preselect or only have the one option to chose from.
My take on the single cert / dual cert situation is to plan the UI & API to work with dual certificates down the line. On the front end, if there is a single cert, then we can hide any selection and just let the user download the cert. A dropdown could be prefilled with no options, or even the dropdown could be selectively rendered.
I think the backend side of this takes even more careful planning. The PR you mentioned introduces an endpoint to generate the debug certificate with a freeform list of algorithms passed in. Katello will need an API endpoint to fetch the types that we know about from the certificate(s) configured by foremanctl. We have no methods yet to interface with a second certificate, but we do have the ability now to load up the one cert that we do support.
So, the API to check this support could perhaps include a commented implementation suggestion (TODO) that can be uncommented once foremanctl configures a second certificate.
Note that I am assuming here that there will be a dual-cert support future.
If we had a configuration in katello that was set based on how Candlepin is configured OR a smart-proxy that advertised the features of Candlepin such as what algorithms are configured, this knowledge could be used to display / validate the options?
Not sure I understand what you mean by “smart-proxy that advertised the features”. Is it like an API that Katello could call and Candlepin returns what algorithms it accepts?
As I understand it, one of the fundamental questions is “what are the capabilities of the Candlepin installation as it is installed and configured?” As we are, especially now, entering a state where Candlepin can be configured in a few different ways and that affects how Katello operates / what it offers the end user.
A smart-proxy with a Candlepin feature could then advertise what the current capabilities are to Katello. The analogy would be how the Pulp smart-proxy tells Katello what content types are available so that Katello shows the user the appropriate set of options.
I don’t understand this situation or how it would happen. Candlepin controls the available algorithms that it can generate a debug certificate for. This is based on how Candlepin is ultimately configured and what CAs are given to it. Therefore, Candlepin broadcasting what it can support seems like the source of truth for what a user could request?
I think what Eric’s getting at here is using the smart proxy paradigm to have Foreman discover what Candlepin can do. I’m not making any judgments here about whether that’s what we should do, but I do want to expand a bit on what that would entail, and I’m sure y’all will tell me if any of this is incorrect
Right now tomcat runs as its own container and service that’s part of foreman.target, but does not show up as a smart proxy (in the UI under Infrastructure > Smart Proxies.) If you go to that page and click on a smart proxy, you’ll see that each smart proxy provides a set of “Features”, e.g. Templates, Registration, Pulpcore, etc.
The idea here would be to have Candlepin running as a Smart Proxy with feature “Candlepin.”
There’s also a way (within a single smart proxy feature) to advertise “capabilities” (I’m not as familiar with this part, but @ekohl is.) That’s where I imagine the specific algorithms would come into play.
As to how we would make Candlepin a smart proxy, there are two approaches -
One is to have the Candlepin team implement the smart proxy API, which would obviously require agreement and work on their end. (This is what we did with Pulpcore, and is the reason why Pulpcore smart proxies always show up as a separate smart proxy record.)
The other is to make a “real” smart proxy repo (along the lines of smart_proxy_container_gateway, etc) that integrates with the foreman-proxy sinatra application.
Okay thank you @jeremylenz for clarifying some things. This makes sense to me, the original PR[1] was merged and currently reads a .pem file to display the valid options we can use. We also have a UI PR[2] that will hopefully be merged soon.
Taking into account the feedback here and what Jeremy mentioned and my personal knowledge on the pulp side I am finding it hard to make a decision on which direction to go. I don’t know the full context on pulpcore, but it seems the smart proxy API sounds like a better option in my mind.
Maybe someone could explain the pros and cons of each option Jeremy mentioned.
I think you are asking about these two options @jeremylenz mentioned:
Getting Candlepin to have a built-in smart-proxy API
Creating a smart-proxy plugin that can be deployed
For option 1, as pointed out, this would require changes in Candlepin and their willigness to support it. With Pulp this was easier because Pulp has a plugin system, and it could be handled out of band of the Pulp project. See pulp_smart_proxy. I think the most challenging part of this approach is the code would live in Candlepin and outside of our direct control.
Option 2, create a smart-proxy plugin is the standard approach. This is how most everything else get’s handled. This could be as part of foreman-proxy or as a stand-alone instance of smart-proxy with just that plugin.
