Bug 1475085
Summary: | [RFE] Migration capabilities between non-FIPS IDM to FIPS IDM | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Chinmay Paradkar <cparadka> |
Component: | ipa | Assignee: | Thomas Woerner <twoerner> |
Status: | CLOSED WONTFIX | QA Contact: | ipa-qe <ipa-qe> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 8.0 | CC: | abokovoy, afarley, cheimes, mkosek, pasik, pcech, pkulkarn, pvoborni, rcritten, steven.w-ctr.mercurio, tscherf, twoerner |
Target Milestone: | rc | Keywords: | FutureFeature |
Target Release: | --- | Flags: | cheimes:
needinfo-
|
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-06-16 07:05:20 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Chinmay Paradkar
2017-07-26 01:42:59 UTC
Upstream ticket: https://pagure.io/freeipa/issue/7090 No, it is *not* possible to migrate an existing IDM installation from a non-FIPS environment to a FIPS compliant installation. This is not a technical problem but a legal and regulatory restriction. I discussed the matter internally with our FIPS expert. He confirmed what I already suspected. It's not permitted to enable FIPS mode on a non-FIPS machine and then claim to be FIPS compliant. To be FIPS compliant any and all cryptographic key material *must* be created in FIPS mode. Further more this cryptographic key material must never leave FIPS environment unless it's securely wrapped and never unwrapped in non-FIPS environments. Simply speaking: as soon as a key is created or comes in contact with a non-FIPS environment, it becomes tainted and violates FIPS compliance. The best we could do is: * create a new IPA realm in FIPS mode * perform a data migration from non-FIPS realm to new FIPS realm with a filter to block all key material The migration must block: * KDC master key, keytabs, and all related Kerberos key material * user passwords * all certificates including CA, service, and user certificates * OTP tokens * SSH keys and fingerprints * DNSSEC KSK and ZSK * all vault entries * AD trust-related key material Effectively the new FIPS installation is a different installation. You'd have to replace all host keytabs, service keytabs, service certs, and CA cert on all clients. Any trust with AD realms have to be re-established, too. Even with rigorous filtering we aren't sure if this migration is going to pass FIPS muster. Your FIPS auditor may flag this migration. Based on https://bugzilla.redhat.com/show_bug.cgi?id=1475085#c10 we closed this RFE as WONTFIX. What about a new feature added to the ipa-backup that will allow you to backup everything that is *NOT* affected by a change to FIPS like users, groups, DNS, etc. so then you are still essentially starting over with a new install BUT you can restore at least some things. Another other option is add a feature to the installer that reads everything it can from one master in the post install process of a new IPA server and creates everything it can to match the old system into the new system. Or a really good option is a tool that just reads the configuration (This could be done in Ansible fairly easily) and creates a list of ipa commands or an ansible yaml file that can be used to create/recreate the same setup similar to how a DB does a dump of SQL commands that can be replayed on a DBV to restore it. In all 3 methods you are essentially starting over BUT you are GREATLY limiting the amount of loss! The added benefit of this is it can be used to solve *MANY* issues like: 1. perform in-place upgrades like from CentOS to RHEL 2. Migrate from non-FIPS to FIPS 3. fixing a corrupted IPA install 4. install a new system that does not have certain things like ad trusts 5. install a new system that is for testing, replicating issues, or a new environment that must match an existing environment In all these cases any of these methods are basically starting over on a new install and would NOT interfere with FIPS in ANY way. There would be some loss like user passwords, certs, etc. but that is a FAR better fate than loosing EVERYTHING and starting over! We have a plan for IPA-IPA migration: https://freeipa.readthedocs.io/en/latest/designs/ipa_to_ipa_migration.html This is not implemented yet, but it is pretty much along the same lines. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days |