Update shell-image to current gcr.io/distroless/base:debug-nonroot SHA

[skaegi]

In #2999 I updated to the latest gcr.io/distroless/base:debug
... it should have been to the latest gcr.io/distroless/base:debug-nonroot

[dlorenc]

Will this cause any trouble like we just saw with the pr init container? #3055

[vdemeester]

@dlorenc #3002 legit failure tends to agree with you 😉

[vdemeester]

So we are running in a pickle. If we start running the internal "containers" as user (with the non-root images), we are running into trouble as soon as user run their task as root. The pull-request failure in v0.15.0 is a good example for that.

Using gcr.io/distroless/base:debug-nonroot causes legit failure (on the CI as #3002 shown before I removed that part of the change). There is a bigger story to discuss and fix here than just switching to those images.

• If we are running internal containers as user, the user containers should also run as user. Overall we should try to aim for this.
• If the user want / need to run containers as root, then we need to run our internal containers as root too, otherwise, we end up with a broken behavior.
• Platform like OpenShift do some magic to run all as random uid by default. The explicit non-root approach lead sometimes to weird behavior on this platform (because it forces a uid).

This means :

• we need to recommend user to run their containers as user (and on the catalog too)
• we may want to have an option to let the user be explicit if they want to run tasks as user or root (and maybe have some default)
• …

I think this will need a TEP 🙃

+1 to a TEP.

Similarly connected is the problem of home directories for those users. I think any requirement or docs around the UID of Steps also has to take into consideration the $HOME directory of those UIDs. This typically means having an entry in /etc/passwd which a loooooot of images do not offer by default for any non-root users. I think OpenShift generates these entries (part of the magic)?

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[vdemeester]

/remove-lifecycle stale

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.