Please note that we're already in Test Freeze for the release-1.28 branch. This means every merged PR will be automatically fast-forwarded via the periodic ci-fast-forward job to the release branch of the upcoming v1.28.0 release.

Fast forwards are scheduled to happen every 6 hours, whereas the most recent run was: Wed Jul 26 10:09:28 UTC 2023.

Hey @rayandas, thank you for your PR! I think those utilities are useful in the kubectl image. We usually tend to avoid images with shell by using distroless, but that might not be ideal for kubectl. However, I'd prefer changing the base image rather than adding tools one by one. We should use the base image that provides more tools out of the box and I think debian-base image that we ship is a good candidate: registry.k8s.io/build-image/debian-base:bookworm-v1.0.0

I'd also like other RelEng folks to take a look at this PR and provide their feedback, so I'm going to cc them.
cc @kubernetes/release-engineering

@xmudrii Sure, that sounds good.

@rayandas Can you also add a release note since this is a user facing change?

/priority important-longterm
/triage accepted

/sig cli
/sig release

@palnabarun Sure thing. I will add a release note.

/hold cancel

/lgtm

/approve
/lgtm

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dims, rayandas, saschagrunert, xmudrii

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

The pull request process is described here

This is pretty much the opposite of our usual distroless-ish images and will have a lot of packages to patch, do we really need all of these utilities? Is there discussion of this list somewhere?

@BenTheElder This is a good point, this is indeed opposite of how we handle images usually. However, this also a bit specific image. Using kubectl without a shell can make user experience bad and limited. Not only that you have to spawn a new container for each command, you're also very limited in terms of what you can do with output. My opinion is that if we ship a kubectl image, it should include shell and the most frequently used tools, otherwise there's no much value in shipping a kubectl image.

I remember some smaller discussions about this on Slack, but I can't find anything. If you think we should discuss this more in-depth, I recommend proposing this as a topic for one of the next SIG Release meetings. 🙂

I think we should be tagging SIG CLI and that the building of the image is not owned by them but the choice of which tools are available probably should be with input from both.

Users are also free to extend the image and lots of kubectl commands do work without any of these tools just fine and now those users have to pay for a much larger and potentially vulnerable image. The issue discussed two distinct use cases

I think we should be tagging SIG CLI and that the building of the image is not owned by them but the choice of which tools are available probably should be with input from both.

I agree that we should involve SIG CLI here as well.

Users are also free to extend the image and lots of kubectl commands do work without any of these tools just fine and now those users have to pay for a much larger and potentially vulnerable image. The issue discussed two distinct use cases

This statement works both ways. Users are also free to build kubectl without any tools if vulnerabilities are their concern.

We have to make a clear distinction here: this is a client image. Client images should be:

• short-running, do something and remove the container
• optimized for user experience and manual interaction as much as possible (this means shell and more tools)

Reality is that this image is going to be affected by vulnerabilities, but reality is also that (almost) none of those vulnerabilities will ever be exploitable in this context. Again, if someone finds this a blocker, I think it's fair to say "please build your own image without any tools, we want to optimize for user experience here".

Then again, I think we need inputs from and on:

• SIG Release: what constitutes a "client image"
• SIG CLI: what tools should we ship as part of that image

Some middle-ground approach might be two build two different images (with and without tools), but I'm not sure I'm fan of that.

One point of disagreement: I would. Like to use this to tell people "run it as a sidecar". It's a clean way to get arbitrary info from the API, subject to your own pod's ServiceAccount and RBAC (important!), and publish it to another container which doesn't understand kube directly.

It's like downward API, but without having to ask kubelet to respect the pod's RBAC

If we publish tooling (eg a Dockerfile) that helps you make your own image using the kubectl from our image, that feels like a nice balance to me.