@pbaity That is in fact the same issue/error.

The custom scc would look like this:

oc apply -f - <<'EOF'
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "true"
    include.release.openshift.io/self-managed-high-availability: "true"
    include.release.openshift.io/single-node-developer: "true"
    kubernetes.io/description: my-custom-scc is a close replica of pipeline scc with privilege escalation.
    release.openshift.io/create-only: "true"
  name: my-custom-scc
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: true
allowedCapabilities:
  - SETFCAP
defaultAddCapabilities: null
fsGroup:
  type: MustRunAs
groups:
  - system:cluster-admins
priority: 10
readOnlyRootFilesystem: false
requiredDropCapabilities:
  - MKNOD
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  type: RunAsAny
volumes:
  - configMap
  - downwardAPI
  - emptyDir
  - persistentVolumeClaim
  - projected
  - secret
 EOF

You could then attach it to your SA that runs the pipeline by doing this:

oc adm policy add-scc-to-user my-custom-scc -z the-service-account-that-runs-the-pipeline

This would be the quickest way to accomplish this, there are other ways as well. Hopefully this works for you.

In 4.12 by default workloads get the restricted-v2 scc, which has allowPrivilegeEscalation: false, which would cause the same issue as the pipeline scc that this tekton operator provides and uses to run tasks. To me, this would still not work, unless the PR opened is accepted (which the maintainers said they won’t accept, which is fine), and the only option is that the user of tekton creates a custom SA and SCC to run their workloads.

Yes, but 4.12 also ships with something called userns, where you can actually run something with restricted-v2 but still be root in the container (and a random uid on the node where that container is). This works today but it had a bug where we would appear as root but could do “root” thing inside (like dnf install …, …) and thus you wouldn’t be able to run podman either. Most recent nightly have a fix for this.

But yes, in general, the only option is that the user of tekton creates a custom SA and SCC to run their workloads – as we do not want to enable “privilege escalation” when the operator is installed, it’s the users (or cluster admin) responsability to do that explicitely. TEP-0085 would help making this “bearable” (aka less verbose) for users 👼🏼

Look into the latest 4.12 and see if the recent fixes helps us cover ~90% of use cases with the default SA and restricted SCC

I am preparing something on this (a doc/blog/…)

@acornett21 Thanks! That worked for me, and saved a lot of time.

I said 'shouldn’t not ‘can’t’, there are cases where root is the only option, but this isn’t one tekton should dictate IMO. Also all of the documents for pipelines-scc point to it being a copy of anyuid SCC which also has RunAsAny.

@ArthurVardevanyan Your first example is more secure, you shouldn’t run containers as root user, especially for applications that are running on production clusters.