Get back to basics with the Admin User

[Callisto13]

Short description
As a user whose OIDC is f’d or cnba to set up OIDC right this second, I can log in as a hardcoded Admin user and get access to my stuff.

Context
This is basically unwinding some of the extensions that have been made to the AdminUser feature. We do not want it so that we end up supporting our own auth provider. We can handle a single Admin user for emergency purposes only. Otherwise we encourage users to have OIDC #1786.

The feature was introduced here #1490 and extended #1624. There is a further PR here #1755.

We basically want to get back to where we were after #1490.

See conversation here.

Acceptance criteria
As a user whose OIDC is f’d or cnba to set up OIDC right this second:

• I can enable the auth env var flag
• I can create a k8s user, with a role binding and suggested scope of roles per the wego docs. This user must be labelled gitops.weave.works/entity: admin-user
• I can navigate to (or be redirected to) the wego /sign_in page
• I can enter just the password of the emergency/admin user (the name field defaults to admin and is uneditable)
• I am able to log in to my dash

[Callisto13]

#1722 (comment)

[SamLR]

This will likely need updates to the admin-user.yaml helm chart (this may also be impacted by #1789 as namespace and name of the resources created in k8s should probably be configurable NB this doesn't mean the username has to be, just that the resources being injected into potentially congested namepaces should be controllable)

[Callisto13]

@AlinaGoaga Does pesto want this one or shall we take it?

[AlinaGoaga]

Hey @Callisto13! I am not sure actually last time we spoke with David we decided it was going to stay as is I believe @davidstauffer. Let's catch up tomorrow, I think we want to keep the style changes and those related to checking for what's been set up in the cluster to update the interface options from 1624. Thanks :) (tagging the rest of the team also @foot @yiannistri)

[davidstauffer]

Hi, I think we need to separate the UX in the GUI from the mechanism that provides those identities. My takeaway from the mentioned conversation is that we concluded:
a) Don't convert into an identity provider. Focusing on providing a single identity, with the option to change the default name from 'admin' to 'customname' to increase security.
b) Keep the GUI UX as it is. Typing username and password. Labelling the fields clearly. We learned that this UX resonates better, after the initial version where the user typed only the password.

[Callisto13]

I would note that it is likely that we will end up changing this UX as it is simply not good. Literally just now I had this conversation:

person: "I set up my admin user, how do I create another user?"
me: "Good question. May I ask what makes you think you can do that?"
person: "... there is a username and password field. What else would I think?"
me: "Well you can't :)"

BUT I do see the value in making the admin username configurable, so hopefully it will work out