Pipeline Service Account does not have enough privileges to build container images

Using Pipelines 1.4 to build pods, it looks to me that the `pipeline-scc` does not have enough privilege for building Container images.

Background:
Customers would like to give their teams the ability to create arbtitrary Tasks including building images, without giving the Team the ability to create privileged pods, which are basically being root on the cluster.

Example task:
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: build
spec:
  steps:
    - name: build
      image: ubi8/ubi
      command: ["/bin/sh"]
      args:
        ["-c", "yum -y install podman; whoami; echo -e 'FROM quay.io/prometheus/busybox\nRUN echo I am busy' | podman --storage-driver=vfs build -"]
 
Extract from the taskrun:
oc get -o json taskrun build | jq '.spec'
{
  "serviceAccountName": "pipeline",
  "taskRef":

,
  "timeout": "1h0m0s"
}
 
and this the pod log
STEP 1: FROM quay.io/prometheus/busybox
Getting image source signatures
Copying blob sha256:aa2a8d90b84cb2a9c422e7005cd166a008ccf22ef5d7d4f07128478585ce35ea
Copying blob sha256:b45d31ee2d7f9f452678a85b0c837c29e12089f31ee8dbac6c8c24dfa4054a30
Copying config sha256:765c5b099deb79705ac7f947580453504f7c5d81d38e1e661b397e2648383815
Writing manifest to image destination
Storing signatures
time="2021-07-06T15:40:56Z" level=error msg="Error while applying layer: ApplyLayer exit status 1 stdout:  stderr: Error creating mount namespace before pivot: operation not permitted"
Error: error creating build container: Error committing the finished image: error adding layer with blob "sha256:aa2a8d90b84cb2a9c422e7005cd166a008ccf22ef5d7d4f07128478585ce35ea": ApplyLayer exit status 1 stdout:  stderr: Error creating mount
namespace before pivot: operation not permitted
 
Current Output:

• Image build is failing

Expected Output:
 - image build is successfull
 
It looks the SYS_ADMIN capabilities is needed, if I rightly correlate the error message with
https://www.mankier.com/2/clone
 
CLONE_NEWNS (since Linux 2.4.19)
If CLONE_NEWNS is set, the cloned child is started in a new mount namespace, initialized with a copy of the namespace of the parent. If CLONE_NEWNS is not set, the child lives in the same mount namespace as the parent.

For further information on mount namespaces, see namespaces(7) and mount_namespaces(7).

Only a privileged process (CAP_SYS_ADMIN) can employ CLONE_NEWNS. It is not permitted to specify both CLONE_NEWNS and CLONE_FS in the same clone call.