Use a UID rather than "nonroot" in the Dockerfile

[dgl]

1. Why is this pull request needed and what does it do?

Since #5969 the Dockerfile has run coredns as USER nonroot:nonroot, but it's not possible to enforce that with Kubernetes as it can only check UIDs.

It changes the UID in the user line to be 65532. This matches distroless's nonroot UID:
https://github.com/GoogleContainerTools/distroless/blob/main/base/base.bzl#L8

(Note that if the Dockerfile didn't override the USER line at all, it would pick up the uid from the distroless image, which uses a UID not a user but I've kept it as is, as it's clearer to someone reading the Dockerfile.)

Also while here bump the distroless base version to match what "stable-slim" now refers to. Given coredns includes its own ca-certificates the difference is very minor.

2. Which issues (if any) are related?

#5969

3. Which documentation changes (if any) need to be made?

n/a

4. Does this introduce a backward incompatible change or deprecation?

No.

[codecov]

Codecov Report

Attention: 757 lines in your changes are missing coverage. Please review.

Comparison is base (93c57b6) 55.70% compared to head (c4532d1) 58.48%.
Report is 1089 commits behind head on master.

Files	Patch %	Lines
core/dnsserver/server_quic.go	9.13%	177 Missing and 2 partials ⚠️
core/dnsserver/register.go	0.00%	93 Missing ⚠️
core/dnsserver/server.go	15.05%	72 Missing and 7 partials ⚠️
plugin/backend_lookup.go	0.00%	37 Missing ⚠️
plugin/forward/dnstap.go	0.00%	30 Missing ⚠️
plugin/dnstap/setup.go	76.59%	17 Missing and 5 partials ⚠️
core/dnsserver/quic.go	23.07%	20 Missing ⚠️
plugin/dnssec/cache.go	32.00%	17 Missing ⚠️
core/dnsserver/onstartup.go	30.00%	14 Missing ⚠️
plugin/bind/setup.go	75.43%	10 Missing and 4 partials ⚠️
... and 41 more

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6416      +/-   ##
==========================================
+ Coverage   55.70%   58.48%   +2.78%     
==========================================
  Files         224      252      +28     
  Lines       10016    16545    +6529     
==========================================
+ Hits         5579     9677    +4098     
- Misses       3978     6279    +2301     
- Partials      459      589     +130     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[polarathene]

If the Dockerfile didn't override the USER line at all, it would pick up the uid from the distroless image
I've kept it as is, as it's clearer to someone reading the Dockerfile

👍

My only concern here is that there is an ARG to allow changing the base if building the image via the Dockerfile, while this enforces a specific USER unless commented out (since it's implicit already). By only having it as a comment for documentation, one could build the image with the distroless root image variant too.

Given coredns includes its own ca-certificates the difference is very minor.

This may change in future as it's been suggested to simplify the Dockerfile, where ca-certificates can rely upon the one provided by the base image instead of copying from the build stage which is not necessary: #6320

If those changes are approved, the feature for a custom base image ARG is less useful due to how minimal Dockerfile becomes, but may still warrant not enforcing a specific USER?

---

Dockerfile has run coredns as USER nonroot:nonroot, but it's not possible to enforce that with Kubernetes as it can only check UIDs.

As you have k8s experience, if you're able to provide any input on why my PR triggered a test failure for it, that'd be appreciated:
#6320 (comment)

Given the description here for the incompatibility with k8s, the test suite must not be running as non-root in the same manner, but not as root either if it's actually dependent upon setcap? (not required on Dockers network stack which relaxes the restriction a bit by default regardless of USER)

[dgl]

By only having it as a comment for documentation, one could build the image with the distroless root image variant too.

It would fail previously, as the user wouldn't exist, but UIDs always work, so now it would work, although run as nonroot without the user existing (which may or not break things, although most Go programs are okay with such things).

Given the description here for the incompatibility with k8s, the test suite must not be running as non-root in the same manner

The incompatibility is only in enforcing it's running as non-root (a security check), "runAsNonRoot" checks that USER is numeric but not 0 (as using a name needs some complex and potentially fragile logic that reads /etc/passwd within the container, i.e. what the image has or even a volume mount... you see why it doesn't implement that).

[polarathene]

It would fail previously, as the user wouldn't exist, but UIDs always work, so now it would work

Isn't the UID already the default user though? The USER instruction isn't actually required in the Dockerfile here to be non-root by default right? That's already the case with the base image, is it different for k8s?

you see why it doesn't implement that

Yes, I am familiar with this issue in Docker land too. I encountered it when using COPY --link --chown to keep the UID+GID of data from another image, it could not user the friendly name, even if it was also present in the target image.