Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 3. Configuring the security context for pods

The default service account for pods that OpenShift Pipelines starts is pipeline. The security context constraint (SCC) associated with the pipeline service account is pipelines-scc. The pipelines-scc SCC is based the anyuid SCC, with minor differences as defined in the following YAML specification:

Example pipelines-scc.yaml snippet

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
# ...
allowedCapabilities:
  - SETFCAP
# ...
fsGroup:
  type: MustRunAs
# ...
Copy to Clipboard Toggle word wrap

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

You can configure the security context for pods that OpenShift Pipelines creates for pipeline runs and task runs. You can make the following changes:

  • Change the default and maximum SCC for all pods
  • Change the default SCC for pods created for pipeline runs and task runs in a particular namespace
  • Configure a particular pipeline run or task run to use a custom SCC and service account
Note

The simplest way to run buildah that ensures all images can build is to run it as root in a pod with the privileged SCC. For instructions about running buildah with more restrictive security settings, see Building of container images using Buildah as a non-root user.

You can configure the default security context constraint (SCC) for all pods that OpenShift Pipelines creates for task runs and pipeline runs. You can also configure the maximum SCC, which is the least restrictive SCC that can be configured for these pods in any namespace.

Procedure

  • Edit the TektonConfig custom resource (CR) by entering the following command: 

    $ oc edit TektonConfig config
    Copy to Clipboard Toggle word wrap

    Set the default and maximum SCC in the spec, as in the following example: 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
#  ...
  platforms:
    openshift:
      scc:
        default: "restricted-v2"
    1 
    
        maxAllowed: "privileged"
    2
    Copy to Clipboard Toggle word wrap
    1
    spec.platforms.openshift.scc.default specifies the default SCC that OpenShift Pipelines attaches to the service account (SA) used for workloads, which is, by default, the pipeline SA. This SCC is used for all pipeline run and task run pods.
    2
    spec.platforms.openshift.scc.maxAllowed specifies the least restrictive SCC that you can configure for pipeline run and task run pods in any namespace. This setting does not apply when you configure a custom SA and SCC in a particular pipeline run or task run.

3.2. Configuring the SCC for pods in a namespace
Copy link

You can configure the security context constraint (SCC) for all pods that OpenShift Pipelines creates for pipeline runs and task runs that you create in a particular namespace. This SCC must not be less restrictive than the maximum SCC that you configured using the TektonConfig CR, in the spec.platforms.openshift.scc.maxAllowed spec.

Procedure

  • Set the operator.tekton.dev/scc annotation for the namespace to the name of the SCC.

    Example namespace annotation for configuring the SCC for OpenShift Pipelines pods

    apiVersion: v1
kind: Namespace
metadata:
  name: test-namespace
  annotations:
    operator.tekton.dev/scc: nonroot
    Copy to Clipboard Toggle word wrap

When using the pipelines-scc security context constraint (SCC) associated with the default pipelines service account, the pipeline run and task run pods might 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
    Copy to Clipboard Toggle word wrap

  2. Create the custom SCC:

    Example: Create the my-scc SCC

    $ oc create -f my-scc.yaml
    Copy to Clipboard Toggle word wrap

  3. Create a custom service account:

    Example: Create a fsgroup-runasany service account

    $ oc create serviceaccount fsgroup-runasany
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

  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'
    Copy to Clipboard Toggle word wrap

    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'
    Copy to Clipboard Toggle word wrap

Back to top
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

© 2025 Red Hat