You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the best practice is to run docker containers as non-root user, jib should provide a standardized way to create users via pom file configuration.
Creating a secure image is right now too cumbersome which pushes users to build less secure builds with jib.
I have seen thread #1029 and know the work around but it worse than using a custom image. And custom image is what I am trying to avoid. It requires you to override the default /etc/passwd and /etc/group files with your own. But what if the source image's next version has some more users/groups that are not there in your external file? That would create a potentially bad build. So this work around is worse than using a custom image with a non-privileged user account already baked in.
I understand that user creation commands can be distro specific. So the solution I see is to either:
Allow user to run arbitrary commands during container creation
OR
Support custom user creation based on pom file config on the default "from" image that jib uses.
The text was updated successfully, but these errors were encountered:
There are certain things in Jib that are inherently or purposely not applicable due to the nature of the Jib paradigm, and one of them is to actually execute a command using some container runtime (mostly a local Docker runtime) during builds: #3278.
But I think it is not impossible to create new /etc/passwd based on the content of the file in a base image in a declarative manner without a command execution on Docker. That is, go through all the layer tarballs of the base image and inspect them to see if any of them has /etc/passwd, extract the file from the tar, read the content, and create a new /etc/passwd in a fresh new layer. (That may impact the Jib performance to some degree though.) It's only that this potential feature will be a pretty low priority and it's unlikely that we'll work on this anytime soon. (We have a lot of back logs of high-impact and high-priority tasks.)
In one of the threads I came across a solution that suggested using the nobdy user. It's UID is 65534.
This UID is predefined in many Linux distros. Every base image I cared for had this user.
I am using this for now.
@PriyankPa do note that using any number may work just fine even if there is no user defined in /etc/passwd for that number. It will just be that a container runtime will run your process with the UID. Because nobody usually doesn't have a home directory (e.g., defined as /nonexistent), I expect picking any number will not be really different from using 65534 for such images.
Since the best practice is to run docker containers as non-root user, jib should provide a standardized way to create users via pom file configuration.
Creating a secure image is right now too cumbersome which pushes users to build less secure builds with jib.
I have seen thread #1029 and know the work around but it worse than using a custom image. And custom image is what I am trying to avoid. It requires you to override the default /etc/passwd and /etc/group files with your own. But what if the source image's next version has some more users/groups that are not there in your external file? That would create a potentially bad build. So this work around is worse than using a custom image with a non-privileged user account already baked in.
I understand that user creation commands can be distro specific. So the solution I see is to either:
OR
The text was updated successfully, but these errors were encountered: