apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
...
allowedCapabilities:
- SETFCAP
...
fsGroup:
type: MustRunAs
...
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:
pipelines-scc.yaml
snippetapiVersion: 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.
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
:
RoleBinding
objectapiVersion: 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. |
ClusterRole
objectapiVersion: 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
.
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. |
Define a custom SCC with the fsGroup.type
parameter set to RunAsAny
:
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
Create the custom SCC:
my-scc
SCC$ oc create -f my-scc.yaml
Create a custom service account:
fsgroup-runasany
service account$ oc create serviceaccount fsgroup-runasany
Associate the custom SCC with the custom service account:
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:
privileged
SCC with the fsgroup-runasany
service account$ oc adm policy add-scc-to-user privileged -z fsgroup-runasany
Use the custom service account in the pipeline run and task run:
fsgroup-runasany
custom service accountapiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
name: <pipeline-run-name>
spec:
pipelineRef:
name: <pipeline-cluster-task-name>
serviceAccountName: 'fsgroup-runasany'
fsgroup-runasany
custom service accountapiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
name: <task-run-name>
spec:
taskRef:
name: <cluster-task-name>
serviceAccountName: 'fsgroup-runasany'
For information on managing SCCs, refer to Managing security context constraints.