This page shows a privilege escalation scenario given that tekton is installed in the cluster and that you can create a namespace (sometimes edit rights are enough)
According to the doc: Tekton is a powerful and flexible open-source framework for creating CI/CD systems, allowing developers to build, test, and deploy across cloud providers and on-premise systems. Both Jenkins and Tekton can be used to test, build and deploy applications, however Tekton is Cloud Native.
With Tekton everything is represented by YAML files. Developers can create Custom Resources (CR) of type Pipelines and specify multiple Tasks in them that they want to run. To run a Pipeline resources of type PipelineRun must be created.
When tekton is installed a service account (sa) called pipeline is created in every namespace. When a Pipeline is ran, a pod will be spawned using this sa called pipeline to run the tasks defined in the YAML file.
The Pipeline service account capabilities
By default, the pipeline service account can use the pipelines-scc capability. This is due to the global default configuration of tekton. Actually, the global config of tekton is also a YAML in an openshift object called TektonConfig that can be seen if you have some reader roles in the cluster.
In any namespace, if you can get the pipeline service account token you will be able to use pipelines-scc.
The Misconfig
The problem is that the default scc that the pipeline sa can use is user controllable. This can be done using a label in the namespace definition. For instance, if I can create a namespace with the following yaml definition:
The tekton operator will give to the pipeline service account in test-namespace the ability to use the scc privileged. This will allow the mounting of the node.
The fix
Tekton documents about how to restrict the override of scc by adding a label in the TektonConfig object.
