Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support external OIDC providers #3084

Closed
christian-posta opened this issue Aug 5, 2020 · 8 comments
Closed

Support external OIDC providers #3084

christian-posta opened this issue Aug 5, 2020 · 8 comments
Assignees
Labels
backlog Triaged Issue added to backlog enhancement This is the preferred way to describe new end-to-end features.
Projects

Comments

@christian-posta
Copy link
Contributor

Right now to use OIDC you have to tie it into the Kube API. On cloud-hosted k8s, it's not easy (or is impossible) to alter the kube api startup config.

Can we support a standalone (Auth0, Keycloak, Dex, etc) OIDC provider?

@christian-posta christian-posta added the enhancement This is the preferred way to describe new end-to-end features. label Aug 5, 2020
@israel-hdez
Copy link
Member

israel-hdez commented Aug 5, 2020

Hi, @christian-posta
We have heard of users that have successfully setup Kiali with Auth0, Keycloak and Dex. But, as you say, Kube API also needs to be setup for integration with the providers.

We can remove the requirement of the OIDC integration in Kube API, but RBAC capabilities will be lost. All users logging into Kiali will share the same privileges, because the OpenID users will be unknown to the API server.

Another approach is to add support for API proxies (like kube-oidc-proxy) where the proxy translates OpenID users to regular kubernetes ServiceAccounts. This was requested in #3042.

What would be your expectation? Do you need RBAC, or are you OK with the shared privileges?

@christian-posta
Copy link
Contributor Author

Supporting cloud customers who cannot modify kube api with #3042 sounds interesting!
Otherwise having an option w/o RBAC for global admin users w/out tying to kube-api would work too.

@israel-hdez israel-hdez self-assigned this Aug 6, 2020
@bethmage
Copy link

bethmage commented Sep 4, 2020

Hi, @israel-hdez
Support for cloud (AKS) customers who only need authentication for admin users will help.

@ceastman-ibm
Copy link

And related to this would be our use case:
Allow a read only view (mainly for our development teams) but have the read only view limited to people that passed the openid authentication.

@jshaughn jshaughn added backlog Triaged Issue added to backlog team/saturn labels Sep 29, 2020
@jshaughn jshaughn added this to Backlog in Sprint 46 via automation Sep 29, 2020
@estevaofay
Copy link

Hi @israel-hdez,
Managed clusters like AKS that support group RBAC rules also do not work.

In our setup we have an AKS cluster with AAD integration enabled. Our idea was to let people use their AAD credentials to access Kiali.
Seeing that Kiali checks with the kube API to check permissions and the fact we cannot edit --oidc flags on a managed cluster makes it impossible to integrate with Azure.
Also, our AKS + AAD integration is based on Rolebindings to Azure's group Ids and User Ids. The fact that groups claim are not supported also makes it difficult to use Kiali in our scenario.

Either using code flow or implicit flow (and generating an otherwise valid JWT) does not seem to work.

I would be happy to provide more details

@israel-hdez
Copy link
Member

@xFayre perhaps, can you open new github issue with your details?
If your AKS + AAD integration is working, you should be able to use Kiali with OpenID. The omission of group claims in Kiali is because we delegate the permission check to Kubernetes. So, rolebindings to GIDs should work fine in Kiali as long as the underlying AKS+AAD works.

I would be interested in knowing what's the error that Kiali is outputting.

@israel-hdez israel-hdez moved this from Backlog to Epics in Sprint 46 Oct 8, 2020
israel-hdez added a commit to israel-hdez/swscore that referenced this issue Oct 8, 2020
go-jose is an implementation of the JOSE standards: JWE, JWS, JWT.

This library is going to be used to verify tokens issued by OpenId providers when Kiali is under a no-RBAC configuration.

Related to kiali#3084
israel-hdez added a commit to israel-hdez/swscore that referenced this issue Oct 8, 2020
@lucasponce lucasponce added this to Backlog in Sprint 47 via automation Oct 9, 2020
@lucasponce lucasponce moved this from Backlog to Epics in Sprint 47 Oct 9, 2020
@lucasponce lucasponce removed this from Epics in Sprint 46 Oct 9, 2020
israel-hdez added a commit to israel-hdez/swscore that referenced this issue Oct 9, 2020
The function is doing all checks that are needed to ensure we can accept the id_token. All checks in this function are delegated to the Kubernetes API when the environment is setup with OIDC integration on all parties (both Kiali and Kubernetes)

Related to kiali#3084
israel-hdez added a commit to israel-hdez/kiali-operator that referenced this issue Oct 14, 2020
By default, `disable_rbac` is "off" assuming users usually want RBAC. If users don't want RBAC this is forcing to explicitly turn off RBAC. Basically, we want people to be aware that users logging into Kiali will all share the same privileges.

Related to kiali/kiali#3084
israel-hdez added a commit to israel-hdez/swscore that referenced this issue Oct 14, 2020
This is for using singleflight.Group which helps into reducing the number of requests to the OpenId Server if several threads are wanting to fetch the discovery data of the server and/or the JSON Web Key Set data.

Related to kiali#3084
israel-hdez added a commit to israel-hdez/swscore that referenced this issue Oct 14, 2020
Multi-thread safety is added to:
* GetJwkFromKeySet (the new one in kiali#3084)
* GetOpenIdMetadata (an existent one)

It's unlikely that an error will happen without this, but it's better to be safe. The main variables thay may lead to race condition issues are `cachedOpenIdMetadata` and `cachedOpenIdKeySet`. If multiple threads want to read these variables and find that no data is cached, then multiple requests will be dispatched to fetch the missing data and also all threads will want to store the fetched data.

These changes are to ensure that only one request will be dispatched to fetch the data even if multiple threads find that there is no cached data. The same fetched data will be returned/shared across all threads that found no cached data and are wanting to retrieve it from the OpenId Server.

Related to kiali#3084
israel-hdez added a commit to israel-hdez/kiali.io that referenced this issue Oct 15, 2020
Adding documentation to configure Kiali with OpenID authentication and
RBAC disabled.

Related kiali/kiali#3084
@lucasponce lucasponce added this to Backlog in Sprint 48 via automation Oct 30, 2020
@lucasponce lucasponce moved this from Backlog to Epics in Sprint 48 Oct 30, 2020
@lucasponce lucasponce removed this from Epics in Sprint 47 Oct 30, 2020
israel-hdez added a commit that referenced this issue Oct 30, 2020
…be possible) (#3310)

* Add go-jose dependency.
  * go-jose is an implementation of the JOSE standards: JWE, JWS, JWT.
  * This library is going to be used to verify tokens issued by OpenId providers when Kiali is under a no-RBAC configuration.
* Add function to fetch the JWKS document from the IdP
* Add function to deeply verify the OpenId token
  * The function is doing all checks that are needed to ensure we can accept the id_token. All checks in this function are delegated to the Kubernetes API when the environment is setup with OIDC integration on all parties (both Kiali and Kubernetes)
* Add configuration to turn on/off RBAC on openid strategy
* Add "golang.org/x/sync" dependency
   * This is for using singleflight.Group which helps into reducing the number of requests to the OpenId Server if several threads are wanting to fetch the discovery data of the server and/or the JSON Web Key Set data.
* Add multi-thread safety to OpenId functions
  * Multi-thread safety is added to: GetJwkFromKeySet (the new one in #3084); GetOpenIdMetadata (an existent one)
  * It's unlikely that an error will happen without this, but it's better to be safe. The main variables thay may lead to race condition issues are `cachedOpenIdMetadata` and `cachedOpenIdKeySet`. If multiple threads want to read these variables and find that no data is cached, then multiple requests will be dispatched to fetch the missing data and also all threads will want to store the fetched data.
  * These changes are to ensure that only one request will be dispatched to fetch the data even if multiple threads find that there is no cached data. The same fetched data will be returned/shared across all threads that found no cached data and are wanting to retrieve it from the OpenId Server.
@jshaughn jshaughn moved this from Epics to In Progress in Sprint 48 Nov 2, 2020
@israel-hdez
Copy link
Member

This was finished in Sprint #47 and Kiali v1.26 is covering this case.
Docs are here https://kiali.io/documentation/latest/configuration/authentication/openid/#_set_up_with_no_rbac_support

Closing as done.

Sprint 48 automation moved this from In Progress to Done Nov 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog Triaged Issue added to backlog enhancement This is the preferred way to describe new end-to-end features.
Projects
No open projects
Sprint 48
  
Done
Development

No branches or pull requests

6 participants