Add FIPS prepare feature enabling FIPS mode on RHEL and CentOS #3344
Conversation
Signed-off-by: Ondrej Moris <[email protected]>
The-Mule
requested review from
psss,
lukaszachy,
happz,
thrix and
janhavlin
as code owners
|
FYI: Is there a way to inhibit feature on distributions other than RHEL and CentOS in feature.py? |
Via https://github.com/teemtee/tmt/blob/main/tmt/steps/prepare/feature/epel-enable.yaml#L23 |
|
|
||
| def is_unsupported(self) -> bool: | ||
| return isinstance(self.guest, (tmt.steps.provision.local.GuestLocal, | ||
| tmt.steps.provision.podman.GuestContainer)) |
There was a problem hiding this comment.
Class enumeration will fail as soon as someone comes up with their own plugin that would not support this operation. I'd recommend adding something like localhost attribute to Guest class, see https://github.com/teemtee/tmt/blob/main/tmt/steps/provision/local.py#L21 - it's set to False by default, localhost plugins sets it to True, and code checks this flag - not the class - when it's deciding about localhost-ish features. So I guess we need something like fips_support or something similar, set it to True by default & False in these two classes.
There was a problem hiding this comment.
Let me think about it. Adding a new flag might not be needed in the end since there is basically an equivalence between fips_support and "is_not_container" and I can most likely detect that in the playbook as well by inspecting init process control groups. That might be more tmt-friendly solution.
There was a problem hiding this comment.
Just to be sure, will such autodetection work with Image mode, a container-ish runtime?
We might add the is_container or similar flag to Guest classes if it turns out it's needed for more than just FIPS. I'd like all involved plugins to see the same picture, i.e. one plugin detecting a fact one way while another one would use completely different steps to discover the same answer would be something I'd wish to address. Not a blocker for now though, just a thought.
Right, I understand that. I would prefer to abort sooner that in the playbook (throwing unsupported exception) but now thinking about that that I guess I will add a task to the playbook that will fail on other distros. |
That would require tmt parsing somehow facts like distro,
Out of curiosity: does it need to fail? I think we shouldn't dive into deep waters, but some day in the future, is FIPS applicable to other distros? |
This adds prepare feature for enabling FIPS mode. Notice that disabling FIPS mode is unsupported and hence not implemented. Moreover, keep in mind that the proper way of enabling FIPS mode is to install the system in FIPS mode. The procedure depicted in the Ansible playbook is the only way of enabling it after installation. Since the procedure requires modification of kernel command line, it only supports Guests that allows that (i.e. not containers). Last but not least, the procedure is only valid for CentOS and RHEL (Fedora FIPS mode is an experimental possibility that has no support at all).
This PR is based on #2773 since I am not allowed to continue the work there.
Relates to #1062
Pull Request Checklist