Este conteúdo não está disponível no idioma selecionado.
Chapter 5. Building of container images using Buildah as a non-root user
Running OpenShift Pipelines as the root user on a container can expose the container processes and the host to other potentially malicious resources. You can reduce this type of exposure by running the workload as a specific non-root user in the container. To run builds of container images using Buildah as a non-root user, you can perform the following steps:
- Define custom service account (SA) and security context constraint (SCC).
-
Configure Buildah to use the
build
user with id1000
. - Start a task run with a custom config map, or integrate it with a pipeline run.
5.1. Configuring custom service account and security context constraint Copiar o linkLink copiado para a área de transferência!
The default pipeline
SA allows using a user id outside of the namespace range. To reduce dependency on the default SA, you can define a custom SA and SCC with necessary cluster role and role bindings for the build
user with user id 1000
.
At this time, enabling the allowPrivilegeEscalation
setting is required for Buildah to run successfully in the container. With this setting, Buildah can leverage SETUID
and SETGID
capabilities when running as a non-root user.
Procedure
Create a custom SA and SCC with necessary cluster role and role bindings.
Example: Custom SA and SCC for used id
1000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 1
- Define a custom SA.
- 2
- Define a custom SCC created based on restricted privileges, with modified
runAsUser
field. - 3
- At this time, enabling the
allowPrivilegeEscalation
setting is required for Buildah to run successfully in the container. With this setting, Buildah can leverageSETUID
andSETGID
capabilities when running as a non-root user. - 4
- Restrict any pod that gets attached with the custom SCC through the custom SA to run as user id
1000
. - 5
- Define a cluster role that uses the custom SCC.
- 6
- Bind the cluster role that uses the custom SCC to the custom SA.
5.2. Configuring Buildah to use build user Copiar o linkLink copiado para a área de transferência!
You can define a Buildah task to use the build
user with user id 1000
.
Procedure
Create a copy of the
buildah
cluster task as an ordinary task.oc get clustertask buildah -o yaml | yq '. |= (del .metadata |= with_entries(select(.key == "name" )))' | yq '.kind="Task"' | yq '.metadata.name="buildah-as-user"' | oc create -f -
$ oc get clustertask buildah -o yaml | yq '. |= (del .metadata |= with_entries(select(.key == "name" )))' | yq '.kind="Task"' | yq '.metadata.name="buildah-as-user"' | oc create -f -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the copied
buildah
task.oc edit task buildah-as-user
$ oc edit task buildah-as-user
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example: Modified Buildah task with
build
userCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. Starting a task run with custom config map, or a pipeline run Copiar o linkLink copiado para a área de transferência!
After defining the custom Buildah cluster task, you can create a TaskRun
object that builds an image as a build
user with user id 1000
. In addition, you can integrate the TaskRun
object as part of a PipelineRun
object.
Procedure
Create a
TaskRun
object with a customConfigMap
andDockerfile
objects.Example: A task run that runs Buildah as user id
1000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow (Optional) Create a pipeline and a corresponding pipeline run.
Example: A pipeline and corresponding pipeline run
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Use the
git-clone
cluster task to fetch the source containing a Dockerfile and build it using the modified Buildah task. - 2
- Refer to the modified Buildah task.
- 3
- Use the service account that you created for the Buildah task.
- 4
- Share data between the
git-clone
task and the modified Buildah task using a persistent volume claim (PVC) created automatically by the controller.
- Start the task run or the pipeline run.
5.4. Limitations of unprivileged builds Copiar o linkLink copiado para a área de transferência!
The process for unprivileged builds works with most Dockerfile
objects. However, there are some known limitations might cause a build to fail:
-
Using the
--mount=type=cache
option might fail due to lack of necessay permissions issues. For more information, see this article. -
Using the
--mount=type=secret
option fails because mounting resources requires additionnal capabilities that are not provided by the custom SCC.
Additional resources