When we deploy the tekton dashboard as readonly, TaskRuns have a delete button when you select one or more items. This delete button actually deletes the TaskRuns.
In readonly mode nothing should be modifyable using the dashboard.
Property | Value
-- | --
Namespace | tekton-pipelines
Version | v0.18.0
ReadOnly | True
Property | Value
-- | --
Namespace | tekton-pipelines
Version | v0.25.0

Thanks for reporting @rouke-broersma. I do see the checkboxes on TaskRuns and have identified the bug but it looks like a purely UI issue. When I attempt to delete the TaskRuns it is blocked as expected due to missing permissions, e.g.:
{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"taskruns.tekton.dev \"log-test-d69l9-r-b4xdp\" is forbidden: User \"system:serviceaccount:tekton-pipelines:tekton-dashboard\" cannot delete resource \"taskruns\" in API group \"tekton.dev\" in the namespace \"test\"","reason":"Forbidden","details":{"name":"log-test-d69l9-r-b4xdp","group":"tekton.dev","kind":"taskruns"},"code":403} (error code 403)
Can you confirm that the TaskRuns are actually deleted when you click the button?
What Kubernetes platform are you running this on? e.g. Docker Desktop, GKE, OpenShift, etc.
On Docker Desktop for example, Kubernetes RBAC rules are not enforced by default, all service accounts are essentially granted cluster admin role so regardless of what rules we configure for the Dashboard in that environment all actions are permitted. Most other platforms do enforce RBAC by default so it should be blocked as expected.
I'll create a fix for the checkboxes showing up when they shouldn't and we'll get a patch release out ASAP.
We are running on AKS with RBAC enabled and I can confirm that the delete action actually deletes the taskruns.
Can you verify the contents of the tekton-dashboard-tenant ClusterRole, for TaskRuns it should only have get, list, and watch enabled.
- apiGroups:
- tekton.dev
resources:
…
- taskruns
…
verbs:
- get
- list
- watch
How did you install the Dashboard? Was it a fresh install or an update to a previous install? If updating a previous install, was that also in read-only mode?
If I'm understanding the ClusterRole correctly this is the relevant part of our manifest:
- apiGroups:
- tekton.dev
resources:
- tasks
- taskruns
- pipelines
- pipelineruns
- pipelineresources
- conditions
- tasks/status
- taskruns/status
- pipelines/status
- pipelineruns/status
- taskruns/finalizers
- pipelineruns/finalizers
verbs:
- get
- list
- watch
The dashboard manifest was updated from:
spec:
containers:
- args:
- --port=9097
- --logout-url=
- --pipelines-namespace=tekton-pipelines
- --triggers-namespace=tekton-pipelines
- --read-only=false
- --log-level=info
- --log-format=json
- --namespace=
- --stream-logs=false
- --external-logs=
To:
spec:
containers:
- args:
- --port=9097
- --logout-url=
- --pipelines-namespace=tekton-pipelines
- --triggers-namespace=tekton-pipelines
- --read-only=true
- --log-level=info
- --log-format=json
- --namespace=
- --stream-logs=false
- --external-logs=
And also from v0.17.0 to v0.18.0 at the same time. We performed this update by taking the upstream dashboard manifest. The only change to the upstream we performed as set readonly to true.
We provide a read-only manifest in our releases to ensure the deployment args, RBAC, etc. are all properly aligned. See for example https://github.com/tektoncd/dashboard/releases/download/v0.18.0/tekton-dashboard-release-readonly.yaml or https://storage.cloud.google.com/tekton-releases/dashboard/previous/v0.18.0/tekton-dashboard-release-readonly.yaml depending on your preferred source.
However, your ClusterRole looks correct. Is it possible you have another Role / ClusterRole granting the tekton-dashboard ServiceAccount additional permissions? I would suggest comparing against the manifest linked above since that has the expected configuration for a read-only install.
I will do that thank you! We probably assumed setting the pod to read-only would be sufficient.
I would like to suggest that the tekton dashboard should display some kind of warning when it is set to read-only but the cluster role is not configured to be read-only as well. Thankfully due to this bug we found out now, otherwise we would not have known that our configuration was not correct.
We're actually considering moving away from the current coarse 'readonly' deployment arg and hoping to adopt more granular / fine-grained control via (Self)SubjectAccessReview requests and similar. This way folks can configure the RBAC to suit their needs and the Dashboard UI will adapt accordingly. For example, some may want to allow users create resources, but NOT delete them. This would also avoid issues with the deployment config and RBAC getting out of sync. It's one of the next big sets of changes we're planning to make.
We would still provide a 'readonly' manifest as part of our releases for convenience, but the underlying mechanism would be more flexible and more resilient to RBAC customization.
v0.18.1 is available now with the fix to hide the checkboxes / delete button
That's awesome!
The fixed dashboard hides the delete button correctly, and changing to the readonly ClusterRole fixed the api permissions! Thanks!
Most helpful comment
v0.18.1 is available now with the fix to hide the checkboxes / delete button