Dashboard: 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.

[tomhau01]

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 https://github.com/tektoncd/dashboard/pull/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: https://github.com/tektoncd/dashboard/issues/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. https://github.com/tektoncd/dashboard/issues/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.

[tomhau01]

/remove-lifecycle stale

[AlanGreene]

This is on the roadmap
/lifecycle frozen