Add KILL capability for Kaniko executor to allow it to kill non-root processes

[SaschaSchwarze0]

Changes

For a RUN something command, Kaniko triggers a process for something. In case something triggers a daemon process, Kaniko must kill this once the main process is terminated. The reason is that the daemon could otherwise continue to make changes to the file system that will fail the layer creation. See RUN <process> can leave processes running in the background #247 for more information.

Kaniko is running as root. If the daemon process runs as a different user, for example because thee is a USER nonroot statement in the Dockerfile before the RUN command, then the KILL capability is necessary.

The Kaniko kill logic is here: run.go.

The Secure Your Containers with this One Weird Trick blog post assesses KILL on the danger scale, this one is on the low end.

A sample Dockerfile that needs this is the Java sample that I added here: sample-java/docker-build. The RUN configure.sh command seems to cause some background process that Kaniko requires the KILL capability because it runs as user 1001. With a PSP in place enforcing the capabilities, the container will fail at this point.

Submitter Checklist

• Includes tests if functionality changed/was added
• Includes docs if changes are user-facing
• Set a kind label on this PR
• Release notes block has been filled in, or marked NONE

Release Notes

Adding the KILL capability to the Kaniko executor to allow it to kill daemon processes started by non-root

[zhangtbj]

Thanks for the fix! And Sascha already verified in our internal env.

/lgtm
/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: zhangtbj

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [zhangtbj]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[imjasonh]

Thanks for adding this! Is this something we should consider adding to the kaniko Task in the Tekton Catalog?

[SaschaSchwarze0]

Thanks for adding this! Is this something we should consider adding to the kaniko Task in the Tekton Catalog?

Feel free to go ahead. Never really looked at this one in the Tekton catalog. Really not a nice one, specifically the digest handling that uses a specific Tekton image and then uses the five years old and probably full of vulnerabilities jq image.