Do actions on behalf of user

[jlpettersson]

Expected behavior

That Dashboard is a secure app and follow cloud native least privilege principles, e.g. using OIDC for authentication

Actual behavior and proposed solutions

Apparently, the dashboard does not provide user authentication #692 and may expose things that the user usually does not have access to (example #1018). It seems that the Dashboard does things using the dashboard service account on behalf of the user e.g. tektoncd/pipeline#2372 (comment), this is a form of privilege escalation as I see it.

When e.g. tkn or kubectl creates PipelineRuns that is done with the users credentials (e.g. kubeconfig), but from a webapp, the cloud native authentication would be that the user is authentication using OpenID Connect.

The dashboard should only show public namespaces or the namespaces that the user has been granted access to. And the user should only be able to create PipelineRuns that he is authorized to do.

I would also like to see that the user is able to re-run a PipelineRun that failed for a temporary reason (e.g. network issues), but without that the user need to have access to the Kubernetes control plane (e.g. developers in our organization does not have access to control plane in production clusters). But still use least privileges security principles. If the user is authenticated with OIDC and sends a request to a Trigger (where the pipeline authors have configured authorization) this should work.

This would solve multiple problems, e.g. Triggers already provide TriggerTemplates for e.g how to create PipelineRun including how to map parameters and volume configuration (that is specific to the pipeline, see use-cases in tektoncd/pipeline#1986 (comment)). This would also solve tektoncd/pipeline#2662 and is also related to tektoncd/pipeline#2372.

Authentication and Authorization is important in an enterprise context especially when used in a multitenant environment.

[eddycharly]

Thanks @jlpettersson for raising the issue.

There’s work going on to limit the scope of the dashboard to a single namespace and reduce RBAC permissions.

I wanted to implement opt-in/opt-out mechanism too but didn’t have time to work on it yet (right now we have no way to tell a service account should not be used for pipeline runs for example, one can execute a pipeline run with cluster admin rights).

Authentication has been discussed in a few issues but no work has been done yet that I know of. All solutions for authentication I am aware of are using secure ingress and don’t propagate to the dashboard itself.

The next big thing is allowing deploying multiple dashboard instances side by side in a cluster, effectively enabling multi tenancy.
We’re not quite there yet but getting closer every day. Apart from pure dev concerns it asks questions on the release and install process for the end user too.

[AlanGreene]

Also see #1416 and #1388 which are attempting to address some aspects of this.

There are other items too as @eddycharly has mentioned. This is an area of active development and feedback is always welcome 👍

[a-roberts]

@jlpettersson with the oauth example work and namespace only installs, do you think some of this is being addressed? Perhaps @eddycharly could provide an update, there's still the question of using the Tekton dashboard service account as opposed to a user's (perhaps we'd allow running with a certain kubeconfig)?

[jlpettersson]

@jlpettersson with the oauth example work and namespace only installs, do you think some of this is being addressed?

That keeps the scope to a single project, yes. But this also introduces UX problems and maintainability problems.

For a larger enterprise - that has compliance requirements - I would like to have access to e.g. to the 5-6 projects that I am involved in - in a single user interface. An Ops person, would only like to need to maintain a single Dashboard app - with its RBAC, upgrades and more.

Larger enterprises already have an identity platform - they want to use it - e.g. Azure Active Directory, Google Identity, GitHub account or Keycloak (Red Hat project) - all these are OpenID Connect protocol - it would be good to be able to add one or more of them.

Perhaps @eddycharly could provide an update, there's still the question of using the Tekton dashboard service account as opposed to a user's (perhaps we'd allow running with a certain kubeconfig)?

This can be implemented in different ways. Using a dashboard service account - may be good - but in addition to other fine graned authorization - so that not all users get the "dashboard service account" privlileges. Using Open Policy Agent for this may be a good solution - in addition to the dashboard-account - and this is compatible with OpenID Connect authentication - both use JWT-tokens.

Similar issue in Triggers: tektoncd/triggers#610

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

[yuzliu]

Hi we also want to limit the UI dashboard for different namespace. Is there any work planned for it?

[AlanGreene]

@yuzliu Limiting the dashboard to a single namespace is being tracked in a different issue: #1018

It's currently available as an experimental feature, you can find some documentation here: https://github.com/tektoncd/dashboard/blob/master/docs/dev/installer.md#installing-for-single-namespace-visibility
and there's an issue open to improve the documentation and promote it from experimental status: #1507

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
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.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
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 rotten

Send feedback to tektoncd/plumbing.

[jlpettersson]

/remove-lifecycle rotten

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

This is still something we want to do. Freezing so it doesn't get auto closed.
/lifecycle frozen