bitnami/kubectl image has vulnerabilities

[NoamGaloz]

What steps did you take and what happened:
[A clear and concise description of what the bug is, and what commands you ran.)
A vulnerability scan on my clusters identified that The bitnami/kubectl image you're using has vulnerabilities.

Here are a few examples-

• Vulnerability in db5.3 5.3.28+dfsg1 (CVE: GHSA-p4jx-5p2x-4pq7)
• Multiple Vulnerabilities in tar 1.34+dfsg (highest CVE: GHSA-vwpx-f983-qg79)
• Multiple Vulnerabilities in glibc 2.31 (highest CVE: GHSA-hqfh-jh33-mj7r)

Would you consider replacing this image with cgr.dev/chainguard/kubectl?
It is way more light and contains only kubectl.

What did you expect to happen:

The output of the following commands will help us better understand what's going on:
(Pasting long output into a GitHub gist or other pastebin is fine.)

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• helm version (use helm version):
• helm chart version and app version (use helm list -n <YOUR NAMESPACE>):
• Kubernetes version (use kubectl version):
• Kubernetes installer & version:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):

[jenting]

Would you consider replacing this image with cgr.dev/chainguard/kubectl?

The kubectl version running aligns with the cluster Kubernetes version by default, unless the user specifies which kubectl version to use.
As far as I know, the cgr.dev/chainguard/kubectl does not offer each kubectl version but only the latest one.
I think the user can overwrite the default kubectl image by updating the values.yaml.

[reitermarkus]

Relatedly, deploying Velero on a new 1.29 cluster is currently broken by default because no bitnami/kubectl:1.29 image exists (yet). See #531.