Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 2. Using pods in a privileged security context

The default configuration of OpenShift Pipelines 1.3.x and later versions does not allow you to run pods with privileged security context, if the pods result from pipeline run or task run. For such pods, the default service account is pipeline, and the security context constraint (SCC) associated with the pipeline service account is pipelines-scc. The pipelines-scc SCC is similar to the anyuid SCC, but with minor differences as defined in the YAML file for the SCC of pipelines:

Example pipelines-scc.yaml snippet

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
...
allowedCapabilities:
  - SETFCAP
...
fsGroup:
  type: MustRunAs
...

In addition, the Buildah cluster task, shipped as part of the OpenShift Pipelines, uses vfs as the default storage driver.

Procedure

To run a pod (resulting from pipeline run or task run) with the privileged security context, do the following modifications:

  • Configure the associated user account or service account to have an explicit SCC. You can perform the configuration using any of the following methods:

    • Run the following command: 

      $ oc adm policy add-scc-to-user <scc-name> -z <service-account-name>

    • Alternatively, modify the YAML files for RoleBinding, and Role or ClusterRole:

      Example RoleBinding object

      apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: service-account-name
      1 
      
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: pipelines-scc-clusterrole
      2 
      
subjects:
- kind: ServiceAccount
  name: pipeline
  namespace: default

      1
      Substitute with an appropriate service account name.
      2
      Substitute with an appropriate cluster role based on the role binding you use.

      Example ClusterRole object

      apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pipelines-scc-clusterrole
      1 
      
rules:
- apiGroups:
  - security.openshift.io
  resourceNames:
  - nonroot
  resources:
  - securitycontextconstraints
  verbs:
  - use

      1
      Substitute with an appropriate cluster role based on the role binding you use.
    Note

    As a best practice, create a copy of the default YAML files and make changes in the duplicate file.

  • If you do not use the vfs storage driver, configure the service account associated with the task run or the pipeline run to have a privileged SCC, and set the security context as privileged: true.

When using the pipelines-scc security context constraint (SCC) associated with the default pipelines service account, the pipeline run and task run pods may face timeouts. This happens because in the default pipelines-scc SCC, the fsGroup.type parameter is set to MustRunAs.

Note

For more information about pod timeouts, see BZ#1995779.

To avoid pod timeouts, you can create a custom SCC with the fsGroup.type parameter set to RunAsAny, and associate it with a custom service account.

Note

As a best practice, use a custom SCC and a custom service account for pipeline runs and task runs. This approach allows greater flexibility and does not break the runs when the defaults are modified during an upgrade.

Procedure

  1. Define a custom SCC with the fsGroup.type parameter set to RunAsAny:

    Example: Custom SCC

    apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: my-scc is a close replica of anyuid scc. pipelines-scc has fsGroup - RunAsAny.
  name: my-scc
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: false
allowedCapabilities: null
defaultAddCapabilities: null
fsGroup:
  type: RunAsAny
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

  2. Create the custom SCC:

    Example: Create the my-scc SCC

    $ oc create -f my-scc.yaml

  3. Create a custom service account:

    Example: Create a fsgroup-runasany service account

    $ oc create serviceaccount fsgroup-runasany

  4. Associate the custom SCC with the custom service account:

    Example: Associate the my-scc SCC with the fsgroup-runasany service account

    $ oc adm policy add-scc-to-user my-scc -z fsgroup-runasany

    If you want to use the custom service account for privileged tasks, you can associate the privileged SCC with the custom service account by running the following command:

    Example: Associate the privileged SCC with the fsgroup-runasany service account

    $ oc adm policy add-scc-to-user privileged -z fsgroup-runasany

  5. Use the custom service account in the pipeline run and task run:

    Example: Pipeline run YAML with fsgroup-runasany custom service account

    apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: <pipeline-run-name>
spec:
  pipelineRef:
    name: <pipeline-cluster-task-name>
  taskRunTemplate:
    serviceAccountName: 'fsgroup-runasany'

    Example: Task run YAML with fsgroup-runasany custom service account

    apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: <task-run-name>
spec:
  taskRef:
    name: <cluster-task-name>
  taskRunTemplate:
    serviceAccountName: 'fsgroup-runasany'

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top