×

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 OpenShift Pipelines, uses vfs as the default storage driver.

Running pipeline run and task run pods with privileged security context

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.

    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.

Running pipeline run and task run by using a custom SCC and a custom service account

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.

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.

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/v1beta1
    kind: PipelineRun
    metadata:
      name: <pipeline-run-name>
    spec:
      pipelineRef:
        name: <pipeline-cluster-task-name>
      serviceAccountName: 'fsgroup-runasany'
    Example: Task run YAML with fsgroup-runasany custom service account
    apiVersion: tekton.dev/v1beta1
    kind: TaskRun
    metadata:
      name: <task-run-name>
    spec:
      taskRef:
        name: <cluster-task-name>
      serviceAccountName: 'fsgroup-runasany'

Additional resources