Dashboard doesn't have authentication

[anxinyf]

Expected Behavior

Tekton dashboard maybe need authentication.

Actual Behavior

Dashboard doesn't have authentication. In this case, anyone who knows ingress hosts name of dashboard can create tekton resources without authentication. It's not safe.

Steps to Reproduce the Problems

1. I create an ingress for dashboard(include "hosts").
2. Sign in on browser with ingress hosts name, but there's no authentication.

Additional Info

Want to use dex

[a-roberts]

Hey @anxinyf, good points - If you're using OpenShift we use the oauth-proxy container so you'll have to log in first to get to the Tekton Dashboard's route (using OIDC - so the same login details as for your OpenShift cluster)

The only other environment we're really known to work on is Docker Desktop which of course is only for development purposes.

So we do have authentication but only if you're running on OpenShift.

We have considered the ability to have different users with different permissions (so one would be able to create certain resources and another would just be able to view them), that's something we're considering as upcoming work and of course we'd welcome any contributions/advice in this area.

[ghost]

We have considered the ability to have different users with different permissions (so one would be able to create certain resources and another would just be able to view them), that's something we're considering as upcoming work and of course we'd welcome any contributions/advice in this area.

+1 on this one! At least having admin and read-only users would be a great start, thats blocking us from deploying dashboard. OIDC and different roles even better :)

[anxinyf]

@a-roberts Yeah, we are considering implementing it using OIDC for Authentication and Authorization in coding :)

And Any other people are doing this? Maybe I can help a little too :)

[plwhite]

We have a use case with multiple users with different credentials. Ideal for me would be if we did much as the K8s dashboard - i.e. user provides access token, and instead of having its own credentials, the dashboard uses the supplied token. If a user does not have the right permissions to read some of the pipelines or to create pipeline runs, then that just falls out with existing Kubernetes RBAC.

[a-roberts]

We have a use case with multiple users with different credentials. Ideal for me would be if we did much as the K8s dashboard - i.e. user provides access token, and instead of having its own credentials, the dashboard uses the supplied token. If a user does not have the right permissions to read some of the pipelines or to create pipeline runs, then that just falls out with existing Kubernetes RBAC.

Yeah, this sounds good too (as well as having read only/write only versions - providing the option to have granularity through tokens and a sense of users).

Indeed we'd have RBAC set up/documented such that users in that namespace wouldn't be able to just get secrets at will for example

I think this is a story we should pursue more of, seeing plenty of interest here!

@anxinyf there's nobody working on this as far as I know, for transparency the main dashboard contributors are spread in Hursley and Raleigh at IBM and we've been focused on doing a 0.3.0 release around Triggers (removing our need for Knative and Istio) at the moment.

The more support/help/suggestions/pull requests we can get the better 😅

[tbe]

If you're using OpenShift we use the oauth-proxy container so you'll have to log in first to get to the Tekton Dashboard's route (using OIDC - so the same login details as for your OpenShift cluster)

Maybe gatekeeper[1] may be an replacement for this in kubernetes? At least for OIDC backed clusters.

[1]https://github.com/keycloak/keycloak-gatekeeper

[ssvinoth22]

Anyupdate on this? Do we have a plan to implement login to tekton dashboard?

[a-roberts]

Hey all, so we've added a section on authentication and authorization in our roadmap here https://github.com/AlanGreene/dashboard/blob/a783793c6e77653971e2efc4ae3a34d3ea5b4325/roadmap.md, design ideas would be welcome in this space - we're hearing that folks are looking for this, I think the next logical step would be to flesh this one out some more.

@eddycharly has started contributing lots as somebody outside of the usual bunch, @AlanGreene is another usual suspect, so opinions welcome. I'm thinking the minimum requirements should be as follows, so here are my two cents...

1. Require as few minimal dependencies as possible (and anything we do rely on should be regularly maintained and suitable for prod use). Perhaps Create SECURITY.md #1329 is of use
2. Not require substantial install changes - should be "kustomizable" so the login solution gets applied as an overlay on top of our existing yaml files (perhaps with the exception of OpenShift as we could continue using oauth-proxy, although if we can replace that it'd be nice too as there are several security issues we've been unable to resolve through it)
3. Use something folks are familiar with (so not a random library that may be awesome but could go away soon - similar to 1)
4. Secure by design! 😅

It would be great to see a prototype developed here - we could start with Docker Desktop (our main dev environment), then look at the implications on OpenShift, and expand to GKE/AWS/Azure etc - depending on how good our testing story is on those atm that may present its own challenges!

If we can leverage a platform's capabilities easily, I'd like us to - so perhaps any login portal we do provide would communicate with the platform's. Open to suggestions, let us know, I'm curious how many boxes the Gatekeeper suggestion helps us with 👀

[AlanGreene]

Also some related discussions happening in other issues, for example: #1018

I have a slightly 'outside the container' (sic 😉) approach I've prototyped (still early days but may be worth exploring more for some use cases) and could demo at the dashboard working group if folks are interested. #1388

[a-roberts]

Also some related discussions happening in other issues, for example: #1018

I have a slightly 'outside the container' (sic 😉) approach I've prototyped (still early days but may be worth exploring more for some use cases) and could demo at the dashboard working group if folks are interested.

I'd be interested yeah, and we can share some screenshots/gain feedback whenever you're ready with the folks here

[mlbiam]

If you could replicate (or even borrow?) the Kubernetes dashboard's approach of either using a passed in header and/or supporting pass through of impersonation headers you'll save yourself quite a bit of development. Direct OIDC support would be great, but if you don't already have a strong session management capability this is likely to be the hardest part to implement and the most likely to be the source of compromise.

[mfuxi]

I would suggest maybe starting with the most simple approach and it's to give the user the ability to add local users to support some sort of control who can access the dashboard and afterwards implement dex maybe similar how it was done in ArgoCD where you can access the application with LDAP/SAML/OKTA and etc...

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[ghost]

/remove-lifecycle stale

[AlanGreene]

This is on the roadmap
/lifecycle frozen

[stefanhenseler]

@AlanGreene Is this actively being worked on? For us, it would be really important to support Kubernetes RBAC for authentication and authorization. Similar to https://kiali.io/documentation/latest/configuration/authentication/token/ and https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/README.md#bearer-token. We use Pomerium, Authservice + Istio to generate tokens and pass it to Kiali, Kubernetes Dashboard, Argo Workflows and other apps that support Kubernetes RBAC. We would like to use the same approach with Tekton dashboard. This would also work with oauth2-proxy on openshift I guess.

[AlanGreene]

It's one of the high priority items on the roadmap. Last week we completed a significant refactoring effort affecting the entire application that makes some aspects of this much easier to approach so we'll be revisiting it in the near future to evaluate next steps.

[mlbiam]

@AlanGreene i wrote the token auth for kiali and the impersonation auth for both kiali and the k8s dashboard. where in the dashboard code would be go source where the services are handled? all i see is main.go

[AlanGreene]

If using an auth proxy in front of the Dashboard, v0.19.0 (which was just released in the last few minutes) should already support passing through Impersonate-* and related headers so there is some basic support for using Kubernetes RBAC to control access. The missing piece is to give the Dashboard ServiceAccount permission to impersonate.

Today we display all actions / navigation items (assuming the Dashboard is not installed in read-only mode), and display errors if the Dashboard ServiceAccount does not have permissions to perform the action (in case of customised RBAC). There's more work required in the front end to handle this gracefully so we will only display actions / navigation items the user actually has permission to use, but hopefully this is useful in the meantime. Related: #1420

[mlbiam]

@AlanGreene finally got around to trying this out. worked perfectly! deployed behind openunison with impersonation enabled, deleted the RoleBinding and ClusterRoleBindings and everything still worked! logged in with a user that had no rights to any tekton objects and it was all errors. this is great! What do you think needs to happen to close this issue? just docs?

[AlanGreene]

That's great to hear, thanks for testing it and confirming @mlbiam. Yes I think some docs would be enough to close this one out. Would you be interested in contributing them? It doesn't have to be very detailed, even just a high level overview of the required changes so someone else could attempt to replicate it in their environment.

The remaining updates related to cleaning up the UI / handling missing permissions more gracefully are covered by other issues.

[mlbiam]

@AlanGreene i'd be happy to!

[DrissiReda]

@mlbiam I'm trying to do so while using keycloak, I think the auth header isn't handled correctly, because if I let oauth2-proxy pass the header to tekton-dashboard, then I get error 401 on everything, despite having proper rbac. When I set --pass-proxy-header to false it works. Care to tell me how you configured tekton/oauth2-proxy for this?

[mlbiam]

@DrissiReda I didn't use oauth2-proxy. I used OpenUnison with impersonation, so we pass the Authorization header of the service account of the proxy (openunison) and then embed impersonation headers to identify the user and groups. tekton-dashboard then passes those to the API server

[DrissiReda]

@mlbiam it should be similar for oatuh2-proxy then, could you show me what rbac files you modified/used?

[tuananh]

@DrissiReda I didn't use oauth2-proxy. I used OpenUnison with impersonation, so we pass the Authorization header of the service account of the proxy (openunison) and then embed impersonation headers to identify the user and groups. tekton-dashboard then passes those to the API server

do you have an example or instruction how to set it up? thank you