-
-
Notifications
You must be signed in to change notification settings - Fork 382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add rootless (alpine) images #4617
base: main
Are you sure you want to change the base?
Conversation
Deployment of preview was successful: https://woodpecker-ci-woodpecker-pr-4617.surge.sh |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4617 +/- ##
==========================================
+ Coverage 28.23% 28.25% +0.01%
==========================================
Files 399 399
Lines 28238 28238
==========================================
+ Hits 7973 7978 +5
+ Misses 19560 19555 -5
Partials 705 705 ☔ View full report in Codecov by Sentry. |
Im a bit confused. The scratch image is not running as root. So in production just use the scratch one and for debugging if you need a shell use the alpine one? For everyday operation I dont see any reason to have a shell. Im fine to make the alpine one rootless by default as this can be reverted by the user easily if needed. |
It is? Unless a different
Exactly this is the problem. Switching the image just for this is tedious. Scratch images are fine for plugins and other "read-only" approaches IMO but the Hence, a better default would be rootless image (i.e. running as an unprivileged non-root user) but having the ability to exec in. This way, one can inspect logs and other things in a limited way.
I'd argue that there should always be a shell paired with an unprivileged user by default for applications like WP. If the scratch image would be replaced by the rootless-alpine one, the alpine one per se would have to be renamed as well then. So then
|
Could you explain why you need a shell for the server container? I use multiple distroless/scratch images in production and there is IMO no need to have a shell for pure binary apps. It is a very common practice to switch images for debugging. Im against adding more flavours due to the not necessary maintenance. As I said Im fine to add a rootless alpine image but this should replace the default alpine one and not the scratch one. |
For all sorts of debugging activities? Inspecting connection issues to the agent, checking ports, grpc, DB connections.
To me, using scratch images is a predated approach to securing containers before the rootless idea became usable/accepted. One should always have the option to undertake the above mentioned checks in a limited and non-destructive environment without having to switch images upfront. |
How often do you need to debug your apps? So yes I do this every time I have to debug something. Tracing network issues can be done outside of the container itself, logs can be written to a volume or even better stdout etc. I disagree that rootless images fix every problem that could be fixed by distroless base containers. So I would like to keep scratch images. No strong opinion on adding other flavours even if I still think rootless alpine should just replace the existing alpine variant. |
Background
Currently, two image variants exist:
The former is a few MB smaller than the alpine one but lacks the ability to exec into it as it has no shell.
The latter has a shell but as both run as
root
user, using the alpine image is somewhat risky.Possible solutions
There are two ways to approach this:
rootless
variant for the alpine variant (-> allows to exec into the pod but without beingroot
)scratch
variant by a rootless alpine variant and make it the defaultWith (1), there would be three image variants that need to be build and maintained. Having this many, possible confusion among users exists. Also sticking with the
scratch
image as the default is not super convenient as adminds always have to switch to the alpine one first for interactive actionsWith (2), there would be only two image variants (
alpine-rootless
andalpine-rootful
). Makingalpine-rootless
the default (i.e. tagging with only semver versions) provides the same security as before because running rootless = same as usingscratch
, one cannot do anything destructive within the container.)It would additionally provide the ability to exec into the container/pod. A possible downside would be that the image is a few MB bigger (e.g. 17mb instead of 13mb for the server image).
I'd like to get a maintainers vote here how to proceed. Based on that, I would like to a add a new docs page which explains the existing tags and their indented usage, similar to what has been added recently to the repository descriptions on DockerHub.
@woodpecker-ci/maintainers
Vote with 🚀 for keeping
scratch
and having a newalpine-rootless
variant.Vote with 👀 for dropping
scratch
and replacing it with the newalpine-rootless
variant.PS: I tested the server and agent images in a k8s instance. The CLI image was tested locally.