Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
1. Why is this pull request needed and what does it do?
TL;DR:
NET_BIND_SERVICE
capability for any user to bind privileged ports isn't required with Docker unless running with--network host
?Dockerfile
and allow those who enforce droppingNET_BIND_SERVICE
to still run thecoredns
binary on unprivileged ports which is more secure of a choice to support.setcap
applying the capability with effective + permitted set is enforcing a requirement for privileges that aren't always necessary. You can still run as non-root without this.Introduced in March 2023 to support non-root feature. It seems largely unnecessary though?
setcap
mandatingNET_BIND_SERVICE
on the/coredns
binary.COPY
forca-certificates.crt
, the image basestatic-debian11:nonroot
already has that (unless theBASE
referenceARG
is changed). I assume that the base image won't be changing much due to the expectation ofUSER nonroot:nonroot
to be successful, thus value of overwriting the contents seems questionable?scratch
image was used for the final stage, it was more compatible then, but was not merged until the switch tononroot
image which added theUSER
directive.ca-certificates.crt
is also from earlier as an improvement for the final stage withscratch
of the image build. Thus no longer important.On a host network, or perhaps a different container run-time you may need to opt for the
setcap
approach? However due to the change in Docker20.10.0
(Dec 2020), non-root users can already bind to ports below 1024:Restore the sysctl restriction and the capability will have an effect when not applied:
The only reason to use the
setcap
call inDockerfile
is to make the/coredns
binary treated as a "capability-dumb binary":root
user can bypass the restriction.setcap
is only in use to bypass the non-root restriction being respected (for any user in the container to leverage, with any port).2. Which issues (if any) are related?
Last issue raised requesting non-root feature:
Reference of unexpected problems from users affected by the non-root approach (which also changed default
WORKDIR
):Earlier attempts to apply the change:
NOTE: PR #4528 at least included a comment providing better context of the capability intent, but it's not been necessary since Docker
20.10.0
(Dec 2020) which for Docker managed networks drops the<=1024
privileged ports.3. Which documentation changes (if any) need to be made?
N/A?
4. Does this introduce a backward incompatible change or deprecation?
1.10.1
Docker image expectation without mandatory capability enforced. The entirebuild
stage is not needed, it's only purpose was to applysetcap
to a pre-builtcoredns
binary.1.10.1
working directory (I could include that, should just beWORKDIR /
).USER nonroot:nonroot
directive shouldn't be necessary as that's already what the image should run with, I left it alone for the visibility.EXPOSE
likewise is not necessary and is effectively documentation.