OIDC role based access control with Keycloak using Istio AuthorizationPolicies

[steadyk]

Hi all,
this a question about whether a certain approach to authorization for access to the Kiali UI is doable and reasonable.

We are currently using Kiali in a Kubernetes cluster with Keycloak and authorization strategy OpenID connect.
Currently we have only authentication for the Kiali UI. We would like to implement authorization based on user roles from our LDAP via Keycloak.

The approach with OpenID integration in Kubernetes and namespace access control, as described in the documentation, doesn't seem to be useful for us, because this would require massive changes in our platform.

So we decided to try handling authorization with Istio AuthorizationPolicies and Keycloak. As far as we understood, Kiali is using authorization code flow. We checked the communication between Kiali and Keycloak and saw the authorization code, but no JWT token afterwards. In the Istio proxy logs we only saw Jwt is missing.

We started looking at the code and also found an issue where the phasing out of JWTs was discussed. So we are unsure whether JWTs are currently used anymore in Kiali.

So our question is: Is the approach of using Istio AuthorizationPolicies to authorize users based on roles from LDAP over Keycloak reasonable/possible?

Based on the answer we would decide whether to explore this further or try another approach.

Thanks in advance for your time.

[nrfox]

Hi @steadyk,

I'm not the most informed person on this topic but I'll try to answer your question.

For all the different auth strategies, Kiali assumes that it will be given a token that it can use to directly communicate with the Kubernetes api server. In the openid strategy this token comes directly from the idp which in your case is keycloak. You can more or less see how this works here:

kiali/business/authentication/openid_auth_controller.go

Lines 1379 to 1390 in d91b83b

	// Create business layer using the id_token
	bsLayer, err := businessInstantiator(&api.AuthInfo{Token: token})
	if err != nil {
	return http.StatusInternalServerError, "Error instantiating the business layer", err
	}
	// Using the namespaces API to check if token is valid. In Kubernetes, the version API seems to allow
	// anonymous access, so it's not feasible to use the version API for token verification.
	nsList, err := bsLayer.Namespace.GetNamespaces(context.TODO())
	if err != nil {
	return http.StatusUnauthorized, "Token is not valid or is expired", err
	}

Kiali gets a token back from the idp and uses it to talk directly to the kubernetes api server to list/get namespaces.

Istio auth policies can help limit what users can talk to Kiali itself but can't limit what Kiali shows to users once they access Kiali. For that, Kiali needs a token that it can use to talk to the kubernetes api server.

Today you have a couple of options:

1. Deploy a reverse proxy that connects to your idp and use the header auth strategy with Kiali. The reverse proxy will give Kiali a token that it can use to communicate with the kube api server based on their configured access in your idp.
2. Use openid with rbac disabled: https://kiali.io/docs/configuration/authentication/openid/#set-up-with-no-namespace-access-control-support. This basically gives you authentication without the authorization so users would need to login to their idp but kiali wouldn't perform any access checks and users would see whatever the kiali service account can see. There's some additional settings to harden this a bit. You can use accessible_namespaces or discovery selectors to restrict what Kiali itself (for every user) has access to. You can also deploy kiali in view only mode.

There's been some talk in the past of having the list of namespaces the user has access to passed in through an identity claim. If this were implemented it might work well with your use case/constraints and the security features istio already offers.

Hope that helps.

[steadyk]

Hi @nrfox,

thanks for taking the time to answer these questions!

For all the different auth strategies, Kiali assumes that it will be given a token that it can use to directly communicate with the Kubernetes api server. In the openid strategy this token comes directly from the idp which in your case is keycloak.
...
Kiali gets a token back from the idp and uses it to talk directly to the kubernetes api server to list/get namespaces.

Since we do not have a Kubernetes OpenID connect integration in our clusters, our hope was to use the received token together with an Istio AuthorizationPolicy to restrict the access based on the roles in the token. At least for a general allow/deny to the whole Kiali UI.

Our rather simple assumption was something like that:

Kiali -> Keycloak (/auth) -> Kiali (code) -> Keycloak (/token) -> Kiali (JWT)

But we were not able to see any access to the Keycloak token endpoint in the browser console (maybe that traffic is somehow hidden?).
At least we don't find any JWT which could be used in an Istio AuthorizationPolicy.

So probably since we use disable_rbac: true Kiali will not ask for a JWT/token at all and we cannot use an Istio Authorization policy in the end.

Istio auth policies can help limit what users can talk to Kiali itself but can't limit what Kiali shows to users once they access Kiali. For that, Kiali needs a token that it can use to talk to the kubernetes api server.

That's a valid hint. Indeed this will only helps to allow/deny the access to Kiali UI in general, not to certain workloads etc. To achieve this an alternative could be to use multiple Kiali instances for different domains.

1. Deploy a reverse proxy that connects to your idp and use the header auth strategy with Kiali. The reverse proxy will give Kiali a token that it can use to communicate with the kube api server based on their configured access in your idp.

That sounds like a possible approach. Although since we do not have a OpenID connect integration in our clusters, RBAC with Kiali might not work, but we could at least allow/deny access to the whole UI. We might take a deeper look into that later on. Thanks!

2. Use openid with rbac disabled: https://kiali.io/docs/configuration/authentication/openid/#set-up-with-no-namespace-access-control-support. This basically gives you authentication without the authorization so users would need to login to their idp but kiali wouldn't perform any access checks and users would see whatever the kiali service account can see. There's some additional settings to harden this a bit. You can use accessible_namespaces or discovery selectors to restrict what Kiali itself (for every user) has access to. You can also deploy kiali in view only mode.

That's the way we use it at the moment. Our Keycloak setup currently just performs authentication but no authorization. This will be done by the client applications based on the roles in the JWT.
If we want to follow this option, we wound need to adapt the Keycloak setup to also authorize certain users. Probably this is also a valid approach if combined with the additional options you mentioned above together with separate Kiali instances.

Since we currently using a cluster-wide Kiali with basic Keycloak authentication, we just discover our options on how to restrict the access to certain users.

Thanks for your suggestions! :-)