Run dashboard as a client application

[AlanGreene]

Expected behavior

I would like to have a dashboard experience running as a client app without requiring a new service running in my cluster. This should also ensure the application is only running with the permissions that I have in the cluster.

Actual behavior

The Dashboard currently requires a service running in the cluster, and provides the same level of access to all users, i.e. all users can act with the same permissions granted to the dashboard service account.

Additional Info

There appear to be 3 main categories of kubernetes UI:

1. services running in the cluster (e.g. kubernetes dashboard / Tekton Dashboard)
2. kubectl plugins, e.g. kui
3. standalone client app, e.g. Octant (deprecated)

Since the Tekton Dashboard is mostly just using the kubernetes APIs directly with very few of its own custom APIs, it should be possible to provide something similar to 2.

In fact, the current Dashboard front end code can be used unmodified as a frontend for kubectl proxy with much of the basic read-only functionality working.

Demoed on the working group call 2020/05/18

Steps:

1. checkout Dashboard repo
2. follow dev instructions to set up environment
3. npm run build (puts static frontend resources in <path_to_dashboard_project>/dist/)
4. kubectl proxy --port 9876 --www="<path_to_dashboard_project>/dist" --www-prefix=/ --api-prefix=/proxy
5. launch browser at http://localhost:9876
6. enjoy 😸

Limitations with unmodified code:

• read-only
  • we currently use the install properties API provided by the dashboard backend to detect whether we should display Import Resources, Create PipelineRun, etc.
• no real-time updates
  • we currently use a custom websocket implementation provided by the Dashboard backend
  • it's possible to use websockets through kubectl proxy directly with some changes to the Dashboard frontend code, it may be possible to detect this and automatically switch approaches but would need further investigation

With some minor modifications to the code we get much closer to the full dashboard experience:

• switch the websocket to use the kubernetes watch APIs on the resource type of interest for any given page
• switch default value for 'read only' attribute in redux store from true to false to enable Import Resources, Create PipelineRun, etc.

There are also some minor differences in behaviour between our proxied APIs and using kubectl proxy, for example in Create PipelineRun our API returns a 200 response with a body containing the created PipelineRun. The API via kubectl proxy returns a 201 with a body. We don't expect a body with a 201 response so only return the headers, meaning the create dialog doesn't get closed automatically. This should be simple enough to remedy.

Obviously we can't expect users to checkout and build the code themselves just to run the Dashboard app. Since all we need is the output of the frontend build we can distribute this in a number of ways, the simplest (?) being hosting a tarball of the static assets and a simple launch script for users to download and run.

TL;DR

The approach I demoed on the working group used a Homebrew Formula (https://github.com/AlanGreene/homebrew-tektoncd/blob/master/Formula/tektoncd-dashboard.rb)

1. install: brew install alangreene/tektoncd/tektoncd-dashboard
2. run: tkn-dashboard (automatically launches browser)

We can build additional behaviour into the install / launch scripts as needed, e.g. detect tenant namespace (#1018) and automatically launch the browser with the corresponding URL, customise features (enable Triggers), etc.

/kind feature

[AverageMarcus]

This approach would be in addition to the existing deployed service option, right?
I like to run the dashboard in my cluster (behind an auth proxy) so I can access the results from my phone while on the go.

---

How do you propose it handles lack of permissions? For example, if I only have read access to PipelineRuns.

[AlanGreene]

Yes this would be in addition to the current model.

We already have a read-only mode for the deployed service, so I would expect it to behave in the same way by disabling any items the user does not have permission to use, e.g. Import Resources, Create PipelineRun, etc.

The permissions handling needs to be more fine grained than what we have today, maybe using SubjectAccessReview / SelfSubjectAccessReview or similar, and ideally would apply to both models.

There's some related work in progress in #1018 to limit dashboard access to a single namespace.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[AlanGreene]

/remove-lifecycle rotten
/reopen

[tekton-robot]

@AlanGreene: Reopened this issue.

In response to this:

/remove-lifecycle rotten
/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[AlanGreene]

We've made some changes to the Dashboard backend APIs and how the frontend code interacts with them since this was last updated so we'll need to revisit this but I suspect it should still largely work as originally demonstrated. Either way we (realistically 'I'...) should document the approach fully (in dev docs?) and add tests to ensure future changes remain compatible with this design.

One of the changes I suspect may cause some trouble is the CSRF token flow, so we should consider how best to disable or modify that when running in this mode.

[AlanGreene]

Some more musings on the CSRF token flow for the kubectl client app approach... Can we disabled the CSRF token flow in the client code based on some config? Where would this config come from? A URL query param is one option but not ideal. It would also be possible to remove it at build time but I'd like to avoid the need to build multiple versions of the client code if possible.

Anyway, first step is to test with the current codebase as described above and see what gaps need to be addressed.

[AlanGreene]

CSRF protection updated to be compatible so that's no longer a concern, and #1907 sets fallback values for properties such as 'ReadOnly' when we detect we're in client mode so that more of the UI is available by default. If the user doesn't have the required permissions to perform a given action we'll surface the error to them.

The next steps would be to improve:

• detection of Triggers install
• checking permissions
  • should we show Import Resources, Create PipelineRun, etc.?
  • which namespaces can the user access? Does this impact the NamespacesDropdown or will it already handle it gracefully?
• ...

[k]

Can this be added to tekton cli? It would be good to tell developers to only install one tool and then they can access the dashboard and automatically uses their kubeconfig

[AlanGreene]

It could be added as an optional plugin and that should work today with the way both pieces are currently set up (add a symlink from ~/config/tkn/plugins/tkn-dashboard to the client so it can be run as tkn dashboard instead of tkn-dashboard) but I'm not sure if it would make sense to include it by default.

[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.

[AlanGreene]

/lifecycle frozen

[AlanGreene]

We should be able to revisit this once #1842 and #2103 are complete as we'll be using a new approach for the websocket connections that's directly compatible with that needed when using kubectl proxy.

For distribution we should consider similar approaches to the Tekton CLI, although we may not provide all of the same options. At a minimum we should provide a tarball, Homebrew support (see the tkn formula for example) for macOS and Linux users, and consider options for Windows users.

[AlanGreene]

Hoping to revisit this in the near future, likely as alpha/experimental for a while to get broader testing and feedback before including as an official install option.

This would also help drive the changes described in #2287 as we'd be far more likely to encounter non-default (from Dashboard's point of view) RBAC.

I'll update the demo Homebrew formula with a new build while doing the Dashboard v0.33 release in the next couple of weeks so we have something more current to play with and can get a better picture of the work required. It would be useful to run the browser E2E tests (or a subset at least) against the Dashboard in this mode.

Once it's in a slightly more polished state we can work on including it in our existing release process and document it properly.

[AlanGreene]

/area roadmap

[AlanGreene]

Published an updated bundle for v0.43.1: https://github.com/alangreene/homebrew-tektoncd
I should have some time in the near future to make this available as part of Dashboard nightly releases at least, with a view to making it available as an official install option some time later.