Operator Console OpenID configuration

[pjuarezd]

Add example configuration by environment variables to enable OpenID in Operator Console.
Added also a README.md document explaining the different options.

[feorlen]

I was unable to make a PR from Pedro's branch. I did a quick edit of the readme to better match the style of the main web docs. This makes it possible to include it into the docs if we decide to do that. Changes attached as a md file, let me know if it is accurate and how I can best apply this to the PR. (There's a lot of small changes throughout the file.)

readme-edits.md

[cesnietor]

@pjuarezd I see that the env variables start with CONSOLE and those were brought from the minio/console project when we split UI parts. So I'm thinking whether it should be CONSOLE or rather OPERATOR_... as the other ones. or could be called OPERATOR_UI.

[pjuarezd]

I was unable to make a PR from Pedro's branch. I did a quick edit of the readme to better match the style of the main web docs. This makes it possible to include it into the docs if we decide to do that. Changes attached as a md file, let me know if it is accurate and how I can best apply this to the PR. (There's a lot of small changes throughout the file.)

readme-edits.md

suggestions applied, thank you @feorlen

[pjuarezd]

@pjuarezd I see that the env variables start with CONSOLE and those were brought from the minio/console project when we split UI parts. So I'm thinking whether it should be CONSOLE or rather OPERATOR_... as the other ones. or could be called OPERATOR_UI.

That is an excellent point @cesnietor, and I agree.

We talked about normalize our env variabe names in Operator in the past, you can see how there is more non-matching env names in the env-variables md doc, that is a pending task to do, probably in another PR? I don't think it will be approved on this one.

[feorlen]

Oops some typos in the new readme text 🙃, added suggestions to fix

[ravindk89]

@pjuarezd , question - what permission are we expecting here? Or can any user on the OIDC server gain full access via this method?

[pjuarezd]

@pjuarezd , question - what permission are we expecting here? Or can any user on the OIDC server gain full access via this method?

This question unfolds in some others:

Who can login with IDP?

I would not say that "any user on the OIDC", but instead any user exisitng in the OIDC realm that the client exists on.

What can a user do once loged in?

Full access, the way it is implemented right now does not have granular access control like minio does with the "policies" attached to an OIDC user.

How can be even further limited which users in the OIDP realm can log-in?

Well, there are a few more settings available in the Operator Console to set using environment variables, but is not that clear to me how those work right now, the scope of this task was to enlight the minimal requred to configure OIDP so maybe a deeper look on those settings could answer that?, Maybe @bexsoft is familiar with the IDP settings and can explain a bit more

CONSOLE_IDP_HMAC_PASSPHRASE ( passphrase to decrypt "access_token")
CONSOLE_IDP_HMAC_SALT (passphrase salt to decrypt "access_token")
CONSOLE_IDP_USERINFO (bool, "on" = true, somenthing else = false) whether the response should include "acces_token"

[ravindk89]

Well, there are a few more settings available in the Operator Console to set using environment variables, but is not that clear to me how those work right now, the scope of this task was to enlight the minimal requred to configure OIDP so maybe a deeper look on those settings could answer that?,

OK - I think this is a minimum requirement for us to migrate this to our webdocs. Otherwise it feels to me a security risk.

I suppose the other route is to direct users to create a standalone realm just for Operator, not sure how much or little of a lift that is.

[pjuarezd]

Well, there are a few more settings available in the Operator Console to set using environment variables, but is not that clear to me how those work right now, the scope of this task was to enlight the minimal requred to configure OIDP so maybe a deeper look on those settings could answer that?,

OK - I think this is a minimum requirement for us to migrate this to our webdocs. Otherwise it feels to me a security risk.

I suppose the other route is to direct users to create a standalone realm just for Operator, not sure how much or little of a lift that is.

I do see as a viable solution the ask to create a dedicated realm to authenticate in Operator Console in the short term, but yeah I see as a potential security risk: "allow anybody in the realm with valid credentials to login full access" if that is not possible.

A fine grain authorization could be implemented in Minio Console like this:

Adding "claims" evaluation, by adding a specific attribute to the user on the OIDP service, then we specify (to Operator Console) which claim evaluate the user must have on login, just like the MINIO_IDENTITY_OPENID_CLAIM_NAME env variable does in MinIO.

This is my 2 cents on how further authorization could be implemented, but rather I would ask to those who implemented this feature (OIDP) in Operator Console, maybe there is already a solution for this.

[shtripat]

couple of tiny ones

[shtripat]

LGTM