Is there a way to run /kaniko/executor as non-root user inside container to build an image?

[karthiravich]

I am trying to run /kaniko/executor in corporate OKD cluster to build docker images as part of CI process using Jenkins. This is the first time we are trying to introduce kaniko in our OKD cluster .

The Jenkins agent workload runs as pod inside the OKD cluster and kaniko runs as a container within the pod.

I could see the kaniko file system is root owned. The current CI process in the org requires the runner pods to execute as non root in the OKD cluster.

Is there a way I can execute the /kaniko/executor as non-root user instead of root?

Kaniko image - gcr.io/kaniko-project/executor:v1.5.1-debug

PS: I tried to build the /kaniko/executor from source and tried adding full permissions (chmod -R 777) to /kaniko and /workspace directories in the Dockerfile and built the new image.

When tried to execute the /kaniko/executor command, got the below error.

Error: error resolving dockerfile path: copying dockerfile: chown /kaniko/Dockerfile: operation not permitted

Any suggestions to get this work?

[karthiravich]

Just to add more info - Similar issue reported here - #2122

But the fix recommended to use runAsUser: 0 for securityContext would not work in my case. Would like to know if there is any other alternative to make it work?

[hown3d]

Kaniko currently relies on being run as root. Rootless execution is currently not implemented since it would need executing inside user namespace and map uids/gids.

[karthiravich]

@hown3d Thanks for the information. Do you know if that feature of running kaniko as non-root user is being considered and if it is planned for some release version?

[hown3d]

I don't think that running as non-root is currently on the roadmap. If you really need rootless execution for builds of dockerfiles, I would use buildah.

[karthiravich]

I tried executing the buildah inside OKD 3.11, but could not proceed with that option as well . That's why thought of using kaniko.

Kept getting the below error

Storing signatures DEBU[0003] Start untar layer ERRO[0003] Error while applying layer: ApplyLayer exit status 1 stdout: stderr: potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid: lchown /etc/gshadow: invalid argument DEBU[0003] Error pulling candidate docker-registry/ci/baseimage:latest: Error committing the finished image: error adding layer with blob "sha256:35807b77a593c1147d13dc926a91dcc3015616ff7307cc30442c5a8e07546283": ApplyLayer exit status 1 stdout: stderr: potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid: lchown /etc/gshadow: invalid argument error creating build container: Error committing the finished image: error adding layer with blob "sha256:35807b77a593c1147d13dc926a91dcc3015616ff7307cc30442c5a8e07546283": ApplyLayer exit status 1 stdout: stderr: potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid: lchown /etc/gshadow: invalid argument

[hown3d]

Sounds alot like this issue: containers/buildah#4049

[karthiravich]

Thanks for sharing . I will take a look at it and come back!

[karthiravich]

Hello. Thank you for sharing the previous link related to buildah issue. I was able to build the latest buildah image from RH catalog, and used it inside the OKD cluster and it worked :).

[mpeaton-ng]

Neither buildah, nor executor will perform root user build operations for me on OCP without runAsUser:0. This is horseshit.

[mirekphd]

It's enough to add --cap-drop=all to drop all capabilities in the official docker run example from here to reproduce the problem, causing an error when kaniko executor tries to copy the Dockerfile to a root-owned location inside the container:
Error: error resolving dockerfile path: copying dockerfile: chown /kaniko/Dockerfile: operation not permitted

But this issue was raised 4 years ago and tagged "wontfix" here: #681

[idrissneumann]

Just so you know, I reproduce the issue recently :

With this pipeline: https://github.com/idrissneumann/action-kaniko/actions/runs/5600342381/jobs/10242584402

And this pr (that tries to change the user that is running the process): https://github.com/idrissneumann/action-kaniko/pull/4/files

[mmohamed]

Hi guys, i'm facing this issue also, do i need to keep this on track or i must to forget about running kaniko container as non root user to build images ?

[Tahedah]

Hey, I'm also running into this issue. Running as non root is sadly required for me as well as using a stricter securityContext for the Kaniko container. If there are any updates on this topic, I would be happy to hear about it.

[zhangguanzhang]

any update?