Questo contenuto non è disponibile nella lingua selezionata.
Chapter 8. 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 extends the anyuid SCC with the minor differences shown in the following YAML specification:
Example pipelines-scc.yaml snippet
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
# ...
allowedCapabilities:
- SETFCAP
# ...
fsGroup:
type: MustRunAs
# ...
In addition, the Buildah 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
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.
8.1. Configuring the default and maximum SCC for pods that OpenShift Pipelines creates Copia collegamentoCollegamento copiato negli appunti!
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 you can configure for these pods in any namespace.
Procedure
Edit the
TektonConfigcustom resource (CR) by entering the following command:$ oc edit TektonConfig configSet 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" maxAllowed: "privileged"default-
spec.platforms.openshift.scc.defaultspecifies the default SCC that OpenShift Pipelines attaches to the service account (SA) used for workloads, which is, by default, thepipelineSA. OpenShift Pipelines uses this SCC for all pipeline run and task run pods. maxAllowed-
spec.platforms.openshift.scc.maxAllowedspecifies 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.
8.2. Configuring the SCC for pods in a namespace Copia collegamentoCollegamento copiato negli appunti!
Configure the security context constraint (SCC) for all pods that OpenShift Pipelines creates for pipeline runs and task runs in a particular namespace.
The SCC must not be less restrictive than the maximum SCC that you configured by using the TektonConfig CR, in the spec.platforms.openshift.scc.maxAllowed spec.
Procedure
Set the
operator.tekton.dev/sccannotation 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
8.3. Running pipeline run and task run by using a custom security context constraint (SCC) and a custom service account Copia collegamentoCollegamento copiato negli appunti!
When using the pipelines-scc SCC associated with the default pipelines service account, the pipeline run and task run pods might face timeouts. This happens because the default pipelines-scc SCC sets the fsGroup.type parameter 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 an upgrade modifies the defaults.
Procedure
Define a custom SCC with the
fsGroup.typeparameter set toRunAsAny: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 - secretCreate the custom SCC:
Example: Create the
my-sccSCC$ oc create -f my-scc.yamlCreate a custom service account:
Example: Create a
fsgroup-runasanyservice account$ oc create serviceaccount fsgroup-runasanyAssociate the custom SCC with the custom service account:
Example: Associate the
my-sccSCC with thefsgroup-runasanyservice account$ oc adm policy add-scc-to-user my-scc -z fsgroup-runasanyIf you want to use the custom service account for privileged tasks, you can associate the
privilegedSCC with the custom service account by running the following command:Example: Associate the
privilegedSCC with thefsgroup-runasanyservice account$ oc adm policy add-scc-to-user privileged -z fsgroup-runasanyUse the custom service account in the pipeline run and task run:
Example: Pipeline run YAML with
fsgroup-runasanycustom service accountapiVersion: 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-runasanycustom service accountapiVersion: tekton.dev/v1 kind: TaskRun metadata: name: <task_run_name> spec: taskRef: name: <cluster_task_name> taskRunTemplate: serviceAccountName: 'fsgroup-runasany'