From 01c8a551a6165546271f7b128ed40b8dc6ffd678 Mon Sep 17 00:00:00 2001 From: Souvik Sarkar Date: Mon, 8 Nov 2021 00:39:56 +0530 Subject: [PATCH] added pod timeout info in privileged scc docs added content incorporated peer review comments typo correction removed a deleted file from git tracking wrapping BZ link in a note more comments Asliegh's comment --- ...pods-in-a-privileged-security-context.adoc | 4 +- ...n-with-custom-scc-and-service-account.adoc | 121 ++++++++++++++++++ 2 files changed, 124 insertions(+), 1 deletion(-) create mode 100644 modules/op-running-pipeline-run-and-task-run-with-custom-scc-and-service-account.adoc diff --git a/cicd/pipelines/using-pods-in-a-privileged-security-context.adoc b/cicd/pipelines/using-pods-in-a-privileged-security-context.adoc index 15e67419f758..46e7670cc559 100644 --- a/cicd/pipelines/using-pods-in-a-privileged-security-context.adoc +++ b/cicd/pipelines/using-pods-in-a-privileged-security-context.adoc @@ -1,4 +1,4 @@ -[id='using-pods-in-a-privileged-security-context'] +[id="using-pods-in-a-privileged-security-context"] = Using pods in a privileged security context include::modules/common-attributes.adoc[] include::modules/pipelines-document-attributes.adoc[] @@ -24,7 +24,9 @@ In addition, the `Buildah` cluster task, shipped as part of the OpenShift Pipeli include::modules/op-running-pipeline-and-task-run-pods-with-privileged-security-context.adoc[leveloffset=+1] +include::modules/op-running-pipeline-run-and-task-run-with-custom-scc-and-service-account.adoc[leveloffset=+1] +[id="additional-references_using-pods-in-a-privileged-security-context"] == Additional resources * For information on managing SCCs, refer to xref:../../authentication/managing-security-context-constraints.adoc[Managing security context constraints]. diff --git a/modules/op-running-pipeline-run-and-task-run-with-custom-scc-and-service-account.adoc b/modules/op-running-pipeline-run-and-task-run-with-custom-scc-and-service-account.adoc new file mode 100644 index 000000000000..eff3ebf1360e --- /dev/null +++ b/modules/op-running-pipeline-run-and-task-run-with-custom-scc-and-service-account.adoc @@ -0,0 +1,121 @@ +[id="op-running-pipeline-run-and-task-run-with-custom-scc-and-service-account_{context}"] += 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`. + +[NOTE] +==== +For more information about pod timeouts, see link:https://bugzilla.redhat.com/show_bug.cgi?id=1995779[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 + +. Define a custom SCC with the `fsGroup.type` parameter set to `RunAsAny`: ++ +.Example: Custom SCC +[source,yaml] +---- +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: ++ +.Example: Create the `my-scc` SCC +[source,terminal] +---- +$ oc create -f my-scc.yaml +---- + +. Create a custom service account: ++ +.Example: Create a `fsgroup-runasany` service account +[source,terminal] +---- +$ oc create serviceaccount fsgroup-runasany +---- + +. Associate the custom SCC with the custom service account: ++ +.Example: Associate the `my-scc` SCC with the `fsgroup-runasany` service account +[source,terminal] +---- +$ 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 +[source,terminal] +---- +$ oc adm policy add-scc-to-user privileged -z fsgroup-runasany +---- + +. Use the custom service account in the pipeline run and task run: ++ +.Example: Pipeline run YAML with `fsgroup-runasany` custom service account +[source,yaml] +---- +apiVersion: tekton.dev/v1beta1 +kind: PipelineRun +metadata: + name: +spec: + pipelineRef: + name: + serviceAccountName: 'fsgroup-runasany' +---- ++ +.Example: Task run YAML with `fsgroup-runasany` custom service account +[source,yaml] +---- +apiVersion: tekton.dev/v1beta1 +kind: TaskRun +metadata: + name: +spec: + taskRef: + name: + serviceAccountName: 'fsgroup-runasany' +----