This RFC aims to follow on previous RFCs that targeted changes to Katello’s client tooling and registration workflows towards deprecating and eventually removing some of our client tools. This RFC specifically targets tools involved with registration workflows. The current set of tools/flows we have are:
katello-consumer-rpm: Handles configuration of subscription-manager and CA certificate placement
katello-client-bootstrap: Used for migrating existing hosts into Foreman/Katello, EL focused as it uses yum/rpm/subscription-mananager under the hood
global registration: New method for registration that is API and template based, built for use in core Foreman as well as plugins (including Katello)
Proposal
Officially deprecate katello-consumer-rpm and katello-client-bootstrap in Katello 4.3 and aim to drop support of both in Katello 4.5. All client registration workflow support would move to global registration and remote execution.
Details
katello-consumer-rpm
Pros
Simple workflow for users
Install RPM
subscription-manager register
An RPM per foreman-proxy configured to point at that proxy
Cons
Inherently insecure
Served over HTTP
Contains the CA certificate in the RPM
Support is limited to RPM clients
Changes to custom CA certificates, ports, hostname all required rebuilding the RPM
The RPM is built on the install platform but targeted at multiple OS versions which makes it hard to keep compatible across clients
Requires switching out RPMs on the system if switching registered proxy
Does not support immutable operating systems such as OSTree where RPMs cannot be installed
katello-client-bootstrap aka bootstrap.py
Pros
Single python script served in /pub that users can access
Cons
Primarily EL focused
Given single python script, have to ensure it works across available Python versions on every client
Benefits of Global Registration
The original RFC for global registration (RFC: Simple & automatic host registration WF) lays out the benefits of that approach. The highlights for replacing these tools is that it’s a single API, usable in Foreman and Katello use cases. The API is inherently more secure than the bootstrap RPM. Further, global registration allows control of the registration workflow, the items being configured at a template level allowing for more programmatic behavior and user customized behavior. Addtionally, this does not require building any platform specific tools (i.e. no RPMs) and can be generated for any smart-proxy from data reported by that proxy.
I’ll start by saying that I think Global Registration is an outstanding feature and I am excited for its future, particularly so for the powerful automation it can enable for sophisticated users. My primary concern that I will lay out here is that I do not think there is a single registration feature that is right for all end users.
I have seen a lot Katello environments where the users span not only separate teams or separate divisions, but even separate companies altogether (i.e. vendor/customer relationship). In these environments, it is common that the sysadmins responsible for the registered host machines are not experienced Katello users; many times they do not have their own login, do not interact with Katello in any direct way outside of registration and patching, do not use the Katello WebUI at all and may not be confident with REST APIs in general, and in some cases may not even know that Katello exists (only that their repositories are coming from “somewhere”). They may not use a great deal of automation and the systems which they administer can be quite heterogeneous.
Global Registration is an amazing feature in general, but for users like these it may not be the right fit for a few reasons:
They do not have prior familiarity with the WebUI, which would be the easier way to use Global Registration
They do not have prior familiarity with a variety of concepts and specific fields they will be asked to populate to generate the registration commands
They are not confident using APIs directly
They need a login or access token
Global registration is highly efficient (in terms of person-hours) at large scale in highly homogeneous and automated environments, but it is slower in more heterogeneous environments when servers may be registered one at a time or in an ad-hoc fashion
By contrast, these users may have a simpler experience registering with the bootstrap RPM:
They describe their content needs to the vendor or Katello admins, who create for them a content lifecycle complete with activation keys
The Katello admins provide them with a list of activation keys to use per server type and two basic commands using simple and familiar tools:
My proposal is that we should not completely remove the Bootstrap RPM and existing registration workflow. Instead, with the installer it would be extremely easy to default this feature to off for new installs with the option to enable it when the Katello admins judge that it serves the needs of their users and the advantages outweigh the drawbacks. NOTE: In this proposal, bootstrap.py would still be deprecated as it mostly used at scale by somewhat more experienced users, and can therefore be fully supplanted by the Global Registration feature. The advantages of this approach would be:
Serve the needs of a wider cross section of end users with a more targeted experience for their use case
Offer choice to Katello admins whether they prefer to enable Bootstrap RPM in addition
Bootstrap RPM requires far less developer maintenance (perhaps EL9 is looming? I am not familiar with challenges that may pose) than bootstrap.py , so we still reap the benefits of deprecating bootstrap.py with very little overhead.
A final comment/question – @ehelms could you kindly elaborate a bit on the security concerns with the bootstrap RPM? My understanding is that making the CA private key available would compromise its security, but sharing the CA certificate is not only relatively safe but also necessary in order for hosts to have trusted communication with the Katello infrastructure.
Thanks for reading – I’m looking forward to hearing anyone’s further thoughts on this topic.
As @Marek_Hulan points out to me often, users do not have to use the Web UI or the API to figure out a registration URL. An organization admin could create a ‘service user’, generate a command with a token and activation key(s) and then hand that out to users that they can then use to register their machines with. One thing I did not mention here is we are looking into a CLI tool that would provide a single command to run to re-configure, register and ensure the host is configured with all the right bits. Global registration also offers methods to revoke or expire access where activation keys are blind access and the only way to revoke access is to delete the activation key.
The user is in theory blindingly downloading an RPM from some place and trusting that it has a CA in it that the host should trust, that said host is getting configured to talk to the right Foreman and subscribing to valid repositories from a trusted source. There is nothing inherently in the current process that verifies the CA in the RPM against a hash the user knows is valid for that CA or the user is not acquiring said CA on their own ahead of time. Global registration has a similar gap at present, in part due to curl’s support for this feature being in newer curl versions IIRC; however, global registration has a path to solve this. I do not see a good way for the RPM based version to support this.
I appreciate continuing to think about the different personas and use cases especially around “anonymous” user access to content that is used. This deprecation proposal is aimed at reducing our tooling overhead, leveling the playing field across different client operating systems and increasing security.
Please redirect me to a different location if this is inappropriate here, I do understand this is a 2 year old thread, but it was the most recent discussion I could find for now. I was looking through recent Satellite documentation and noticed that the consumer RPM is marked as deprecated since 6.9. We have a use case where we deploy VMs (using whatever method), then we configure them fully using Ansible, including the ansible.builtin.yum module to install the RPM and the community.general.redhat_subscription module to register the host. Our playbook runs continously throughout the week, so if the RPM is updated on capsule, our servers get the newest version automatically. Our concern is if the RPM goes away some day, what would our automation workflow look like with the new UI-based registration tool, I notice it generates a bash script with some JWT tokens in it and not sure how to migrate from our current solution to the new one.
