Dockerfile: add minimal image

[marquiz]

Build a "minimal" variant of the nfd image based on
gcr.io/distroless/base. The motivations behind the minimal image are
image hardening (security) and reducing the image footprint (from ca.
108MB down to about 40MB).

The practical effect of deploying the minimal image is that no runtimes
for running worker hooks are present, not even a shell. This means that
only statically linked linked hook binaries are supported. Also, because
of the image hardening live debugging of the minimal image by attaching
to the container is not possible, and, the "full" image needs to be used
for that purpose.

This doesn't change the default usage/deployment of NFD in any way. Just adds a new image variant that can be alternatively deployed. The minimal variant might become the default in the future, though

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: marquiz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [marquiz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[marquiz]

Pondering that should the minimal image be based on vgcr.io/distroless/base, instead. That would add a bit more flexibility to the hooks, supporting statically linked C binaries, for example.
/hold

[marquiz]

/cc mythi kad

[k8s-ci-robot]

@marquiz: GitHub didn't allow me to request PR reviews from the following users: mythi.

Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/cc mythi kad

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[zvonkok]

Makes sense. Moving forward if it becomes "the" default we should explicitly mention it in the documentation. We had #247 for explaining the runtime options. When already minimal we could also add readOnlyFilesystem: true to the security context.

[marquiz]

Moving forward if it becomes "the" default we should explicitly mention it in the documentation.

Yes, sure. This PR adds a note about lack of runtimes in the minimal image .

[ArangoGutierrez]

Debugging minimal images is...fun, but this PR looks good
/lgtm

[marquiz]

@zvonkok @mythi @kad @adrianchiris any thoughts on distroless/static vs. distroless/base?

[mythi]

@zvonkok @mythi @kad @adrianchiris any thoughts on distroless/static vs. distroless/base

Would distroless/static set too tight restrictions to existing non-static source hooks, i.e., users cannot move to minimal without also updating their own hooks?

[adrianchiris]

@zvonkok @mythi @kad @adrianchiris any thoughts on distroless/static vs. distroless/base

So, going through this PR, i did not find the motivation to provide such an image (also no related issue on it).
e.g smaller footprint, security (is that obvious and should not be mentioned ?)

My main concern with this (and in the future moving to this image by default) are:

1. Possibly breaking existing hooks which may not run or may run and fail due to the change to minimal image. These would need to be recompiled statically.
2. Feature sources cannot rely on OS tooling (i know they dont today, but this kinda shuts the door down the road)
3. Debugging

In regards to static vs base : i would go with base as to give hooks that are not written in go a chance.

[marquiz]

So, going through this PR, i did not find the motivation to provide such an image (also no related issue on it).

Yeah, this was kind of quick spin-off from #221.

e.g smaller footprint, security (is that obvious and should not be mentioned ?)

Yes, these are the motivations behind this. I need to explain that in the commit message.

My main concern with this (and in the future moving to this image by default) are:

1. Possibly breaking existing hooks which may not run or may run and fail due to the change to minimal image. These would need to be recompiled statically.

Yes. This might be too strict and base would be a better choice

2. Feature sources cannot rely on OS tooling (i know they dont today, but this kinda shuts the door down the road)

True. We have been deliberately avoiding this dependency. I think it's good as we (at least so far) have detected low-level features that are mainly available from kernel interfaces.

This doesn't shut the door for using such tools in the future, though (if we choose the base image). We just need to install the tool and the libraries it depends on. I actually think that this is also good as it really makes you consider what and how to contain in the image.

3. Debugging

The full image can be used for debugging. I think it's actually desirable from the security point of view to not be able to attach to running production containers. It vastly reduces the attack surface.

In regards to static vs base : i would go with base as to give hooks that are not written in go a chance.

Yes, after sleeping over this PR I'm inclined to agree with this.

[marquiz]

Would distroless/static set too tight restrictions to existing non-static source hooks, i.e., users cannot move to minimal without also updating their own hooks?

Yes, I think so. Only supporting "fully static" binaries is probably unnecessarily strict, limiting hooks practically only to statically linked Go binaries. With base we will have gllibc which improves the support considerably

[marquiz]

My main concern with this (and in the future moving to this image by default)

Moving to minimal image by default must be carefully considered and I don't see it happening anytime soon. We're kind of held captive by the hooks, which I don't have any idea how widespread their usage is 🤔 Might be that nobody uses them and would even notice the change

[marquiz]

Changed the base image to be base on distroless/base. Improved commit message of the first patch.

[adrianchiris]

Thanks for addressing my comments @marquiz.

/lgtm

[marquiz]

Looks like there's a sort of consensus on this. And, the minimal image is optional, anyway.
/unhold