Kiali: Support OAuth login (OpenID connect)

Created on 19 Dec 2019  路  10Comments  路  Source: kiali/kiali

Is your feature request related to a problem? Please describe.
We use Keycloak for user authentication for all of our components, would like to have in built support in Kiali (like Grafana). Right now we have a sidecar proxy that does this for us, but it's very inefficient as every single request (including prometheus queries) require to go through the authentication first which makes everything slow.

Describe the solution you'd like
Kiali supports OAuth 2.0 natively with OpenID connect integration (Keycloak)

Describe alternatives you've considered
Used Gatekeeper for Keycloak as a sidecar but it makes everything extremely slow.

Additional context
UI could bring a SSO button instead of username and password which redirects to our OpenID system based on Keycloak. Rest of the changes are in backend. Would prefer only user authentication to happen via this mechanism, prometheus/Jaeger/Grafana queries can still without auth.

backlog enhancement epic subtask frontend changes required operator changes required teasaturn

Most helpful comment

@harpratap, and all people following this thread: I'm closing because OpenID login has been implemented and will be released in Kiali v1.19 this Friday.

A brief documentation is coming shortly (follow #2864).

All 10 comments

Thanks for the issue @harpratap.
For the specific OpenShift platform there is a native integration, what platform are you using ?

Also, in OpenShift, Kiali delegates to the user's RBAC rights, I guess with the feature request you propose here, you mean only authentication, right ? But do you envision also to touch the authorization part managed by Keycloack ?

Thanks for the issue @harpratap.
For the specific OpenShift platform there is a native integration, what platform are you using ?

It's an on-prem cluster we built on bare metal. Not using any provider

Also, in OpenShift, Kiali deletages in the user's RBAC rights, I guess with the feature request you propose here, you mean only authentication, right ? But do you envision also to touch the authorization part managed by Keycloack ?

Yes, the RBAC controls what Kiali can/cannot do in the kubernetes cluster. But anyone who has access to the UI of Kiali is able to make use of whatever permissions Kiali has access to. So we want to provide access to only the authenticated users (which we manage via groups made in Keycloak). We personally don't need authorization (we just use RBAC for it and works fine for our use case).

Yes, the RBAC controls what Kiali can/cannot do in the kubernetes cluster. But anyone who has access to the UI of Kiali is able to make use of whatever permissions Kiali has access to. So we want to provide access to only the authenticated users (which we manage via groups made in Keycloak). We personally don't need authorization (we just use RBAC for it and works fine for our use case).

Yes, also, that is the mechanism used by Kiali in one of the providers (OpenShift) where the user's token is used internally to perform the queries to the k8s API allowing to RBAC to act per user granularity.

In others environments, the Kiali ServiceAccount is used instead (which permissions can be controlled at that level).

I guess the issue scope is clear, the how is what it needs more thinking as it needs to study how to combine all these scenarios.

If anyone in the community wants to assist with implementing this (e.g. with Keycloak), here's some info of how Kubernetes works just as reference:

https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens
https://github.com/kubernetes/dashboard/issues/2630
https://github.com/kubernetes/dashboard/issues/2353
https://github.com/kubernetes/dashboard/issues/3148

Moving to sprint for implementation.

Part of epic #2239

Progress on:

  • Operator side: kiali/kiali-operator#42
  • Back-end side: kiali/kiali#2798
  • Front-end side: kiali/kiali-ui#1799

@israel-hdez I ran the latest PRs and it works. I do have a question though, and it probably involves making sure we document things properly.

I installed my cluster with Dex, then installed Istio. At this point, I need to give my user some permissions, so all I did was this:

kubectl create namespace bookinfo
kubectl create rolebinding openid-rolebinding-bookinfo --clusterrole=kiali [email protected] --namespace=bookinfo

Note that I didn't even install the bookinfo demo (I just created the namespace).

I then installed Kiali and logged in successfully as [email protected]. At this point, I got an error message in Kiali that said:

deployments.apps is forbidden: User "[email protected]" cannot list resource "deployments" in API group "apps" in the namespace "istio-system"

So it appears that users must be able to see the istio-system namespace (in this particular case, having permission to list deployments in istio-system ns, but I assume other permissions will also be required).

Therefore, we really need to document somewhere (did we do this already?) what permissions users need to be given in order to work properly with Kiali.

@jmazzitelli

I installed my cluster with Dex, then installed Istio. At this point, I need to give my user some permissions

Therefore, we really need to document somewhere (did we do this already?) what permissions users need to be given in order to work properly with Kiali.

It appears there is a feature in Kiali that is assuming some privileges in _istio-system_ namespace.

I think this is a broader issue because we are mainly testing with cluster-wide privileges and not taking into account the "reduced privileges" use case (remember that the installation is, by default, setting up credentials with cluster-wide permissions for both "login" and "openshift" strategies). I think whatever is that feature, it should just fail with a warning (or no warning at all) rather than an error, and get deactivated if there are not enough privs.

When you are assigning privileges the way you did (only to bookinfo namespace), you are setting up an user with "reduced privileges" and, IMO, that's quite fine! You may not want all users to see the _istio-system_ namespace.

The reason I think this is a broader issue is because the "reduced permissions" case is also possible in OpenShift (see the outdated doc in the website). If you setup an OpenShift user with reduced privs, I could bet that that user will get the same errors you saw here.

@harpratap, and all people following this thread: I'm closing because OpenID login has been implemented and will be released in Kiali v1.19 this Friday.

A brief documentation is coming shortly (follow #2864).

Was this page helpful?
0 / 5 - 0 ratings