packaging: fix ovirt ovn provider for keycloak

[arso]

This patch fixes ovirt ovn credentials after keycloak is re-enabled.
The original issue is caused by the fact that setup code responsible for
updating ovn provider credentials (os configuration and ovirt engine db) is only
triggered on first 'new' ovn provider installation. The result is that
user had to

1. manually update:
   /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
   to add additional line under 'Ovirt' section:
   ovirt-admin-user-name=admin@ovirt@internalsso

2. in Administration Panel update Providers -> OVN provider ->
   username&password to match the above

This patch depends on:

• Fix SSO authentication on keycloak activation ovirt-engine-keycloak#38
  and resolves:
• Fix ovirt-provider-ovn credentials when keycloak authentication re-enabled ovirt-engine-keycloak#19

[arso]

Adding the description I prepared offline for Eitan. Perhaps it could be useful for other reviewers.

"The motivation behind this change is the scenario when we have existing ovirt engine installation ie. 4.4 or 4.5 without keycloak. Now a user wants to enable keycloak because is ready to migrate it's user base backend (db or ldap or something totally different ie. integrate with google or github sso) to keycloak. The initial version of ovirt keyloak support assumed that keycloak can be only 'activated' on new (clean) installations (first setup).
For the first setup execution all required ovn provider config is prepared and then on subsequent engine-setup runs it is not modified (unless requested to reconfigure). That means both ovirt database provider config and /etc/ovirt-ovn/conf/*.
Now, in the affected scenario user runs engine-setup with keycloak 'enabled' flag. Before this patch (and dependent ones) ovn provider was not modified because it was already done so the provider was unable to authenticate with 'new' keycloak credentials.
in ovirt-engine ovn provider setup code I have extracted relevant pieces of code that are responsible for updating provider in db and updating OS config
and in corresponding ovirt-engine-keycloak patch, I also adjusted the code to setup necessary variables in the correct timing. ie. before it's needed by ovn provider setup from ovirt-engine.
One important assumption - we don't support automatic reverting from keycloak to legacy AAA and we don't plan to
however, it is possible to do it manually
fairly easy IMO
I guess the most difficult thing here was to figure out the order how some plugins are executed and make it work together with ovirt-engine-keycloak setup code ( all those conditions and before/after rules).
I'm going to document all the flows, most likely I won't be able to complete it today but definitely early next week "

[almusil]

LGTM

[didib]

With no further condition? Consider this:

1. Run engine-setup without keycloak
2. Run engine-setup enabling keycloak the first time - this is the run for which you are writing the current patch
3. Run again engine-setup, e.g. for an upgrade

It seems like you'll ask for credentials also on (3.).

[arso]

It is only asking for confirmation whether to use the keycloak sso credentials:
Use default credentials (admin@ovirt@internalsso) for ovirt-provider-ovn (Yes, No) [Yes]:
After some consideration, I agree it does not make any sense because, in order for ovn provider work correctly, it needs the keycloak sso credentials. I will make an update to include this requirement and skip user question (3).

[didib]

It will also ask for the credentials themselves, because on upgrades we do not have the admin password.

[arso]

So, do you say that on upgrade, the 'postinstall' file is not used? In ovirt-engine-keycloak there this code snippet:

  @osetupattrs(
        answerfile=True,
        postinstallfile=True,
        is_secret=True,
    )
    def ADMIN_PASSWORD(self):
        return 'OVESETUP_KEYCLOAK_CONFIG/adminPassword'

I had an impression that postinstallfile annotation would handle this 'upgrade' case so that no new keycloak password is required, or was I totally wrong?

[didib]

No, you got it exactly right. My fault. For the internal engine admin password, we deliberately do not save it, because the user can change it later. Isn't it so also for keycloak?

[arso]

Unfortunately, I have not considered this scenario at all. You're right - it is possible to change admin@ovirt & admin (keycloak admin console) passwords.

[didib]

Same

[arso]

In this case, when subsequent engine-setup is executed on environment with already enabled keycloak, the ovirt provider ovn config /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf will be simply rewritten. This is not the prettiest approach, but it is harmless and I think I saw similar cases elsewhere in setup code. No additional credentials related questions are supposed to be asked.

[didib]

You are right that there are many other such cases, as I noted in the dwh patch. It will not even be rewritten, because filetransaction won't rewrite it if it already has the content we want. And the secret key is saved in postinstall, and AFAICT with this the content indeed will be the same. Didn't test.

However, if you do accept my suggestion to add a var CONFIGURED, perhaps better use it here too. Or not, if you think it's better to overwrite if needed. In the original place we added CONFIGURED, we actually eventually had to partially ignore it, because we wanted to make further changes to the ssl conf file (and later also had to revert that, due to wanting to rely on crypto-policies, but that's a different story...).

[didib]

Again. Not terribly bad, as I hope it will be harmless, but perhaps better check if we need to update.

Not sure how to best do this, exactly. If you do indeed add a 'KeycloakEnv.CONFIGURED' as discussed in the dwh patch, perhaps you can condition on this - update ovn only if keycloak is ENABLEd but not yet CONFIGURED.

And, to clarify (as I didn't write this in the dwh patch, sorry): I think they should both be in your current KeycloakEnv in engine_common/constants.py and used only from there everywhere - not duplicate ENABLE/D or CONFIGURED in dwh or ovirt-engine-keycloak.

[arso]

That makes sense. Originally I planned to make that unification after those patches/fixes, but I can see the benefits of having it much earlier. I am going to give it a try now, when the patches are, more or less, doing what they are supposed to do.

[arso]

Just to update you about the current state.
I have implemented the following:

1. All 'common/shared' keycloak variables moved to ovirt-engine package. ie. ENABLE
2. CONFIGURED variable introduced by one of already existing configuration properties. This addition greatly simplified the keycloak activation logic.

Now, I was able to successfully verify all flows I had in mind. Please note, that it is not possible to 'activate' keycloak on already existing environments with just:
engine-setup --reconfigure-optional-components
In order to do that use:
engine-setup --otopi-environment="OVESETUP_CONFIG/keycloakEnable=bool:True"

The reasoning is explained at https://github.com/oVirt/ovirt-engine-keycloak/pull/38/files#diff-214f54e42c9224e0585091f1e23b595d84ed4a044c3d0f35a19aab57fc853cbbR56

[mwperina]

+1