Well, to get that on some external system, you need to have a valid puppet cert. So building the correct curl command becomes a bit harder. For the CA recovery scenario, we should make it as simple as possible.
I want to try and summarize all the use cases, actions and ways to apply those actions in a single table. Hopefully it will make it a bit more clear
New hosts | Maintenance | CA recovery | Images | ||||
---|---|---|---|---|---|---|---|
Global Registration | Kickstart | Script | Config management | Remote Execution | Script | Image generation | |
CA update | snippet | snippet | Downloadable script | ENC | Predefined job template | Downloadable script | Raw certificate |
Sub-man redirection | snippet | snippet | – | ENC | snippet | – | ? |
Connection to Foreman | snippet | snippet | – | ENC + native tools | – | – | ? |
Specifically here we are talking only about the first row (CA update).
It means that if we want to support all the cases we will need:
- a snippet
- a template that will be exposed as a downloadable script
- a template that will be exposed as a raw certificate
- Job templates that will consume the snippets.
In order to satisfy 2 and 3, we will need to add an ability to expose templates without authentication.
In the current state, the PR already implements those parts.
As in the remote execution script provider, via an API? Or some other method?
What does the user interact with? An API? Let’s call that out specifically.
I think for me to better understand this, it goes to my questions above. And it would help to specify more clearly what the user is interacting with.
Downloadable through a simple curl command: foreman.example.com/unattended/anonymous/foreman_ca_refresh
. I will make it available through HTTP
, so in case the CA is already broken on the client, it will be possible to download it.
The same as previous, a pure URI that can be accessed using curl or wget: foreman.example.com/unattended/anonymous/foreman_raw_ca
, to make sure wget -O new_ca.crt foreman.example.com/unattended/anonymous/foreman_raw_ca
will just work.
So for people who want to update the certs in advance (like Ewoud mentioned before), we will have snippets, Remote Execution job templates and ENC and in case the certs on Foreman were already updated, we will have the option to get them with a minimal effort.
Only one thing to add, I don’t like anonymous
term here. The download is certainly not anonymous, the origin IP is recorded in the production.log. It is rather unauthenticated
, which is terrible word to type, so I’d prefer to use public
, which I think clearly designate the purpose of this template kind.
Sure! I will change the anonymous
to public
. Thanks for the suggestion.
Unless I am missing something here, I think we can draw a conclusion on this RFE:
For the CA replacement we will need to expose the certificates as snippets, Remote Execution templates and ENC for people who want to plan in advance. For cases where Foreman’s certificates has already been changed, we should expose a script and a raw template that will be available for download using HTTP.
This is implemented in Fixes #37601 - Add Foreman CA refresh template by ShimShtein · Pull Request #10208 · theforeman/foreman · GitHub and the additional PRs mentioned there.
I guess, we should also update / change this section in hostname-change script:
And here are the changes to the hostname-change script: Direct the users to use the new CA refresh script instead of the rpm by ShimShtein · Pull Request #11079 · theforeman/foreman-packaging · GitHub
Is the plan to completely remove the contents of the /pub? If so, can you create a redirect in Apache so people who are reaching out for katello-consumer-ca.crt
will be redirected appropriately to the template endpoint?
Not sure for other files, but I really do think that the CA bootstrapping should not be broken there are many other boostrapping scripts which are not only for client registrations but various scripts which call REST API and this is the ultimate place where you can find the CA TLS cert.
The end goal is indeed to get rid of katello-ca-consumer.rpm
and katello-rhsm-consumer
script.
Although here I am talking more about one specific aspect that is present in both use cases: updating the CA file on hosts to securely connect to Foreman server.
I will publish soon an RFC about the katello-rhsm-consumer
script, and then I will be able to start thinking about the katello-ca-consumer.rpm
.