Upgrade external-provisioner to use Debian 12 Distroless

[jhawkins1]

Is your feature request related to a problem?/Why is this needed

Describe the solution you'd like in detail

Since Debian 12 Distroless is available, as well as, the latest releases of Kubernetes and many of the Kubernetes related projects have moved to Debian 12, we would request that external-provisioner move to Debian 12 Distroless to align with other Kubernetes components.

Benefits: Alignment of the Container OS being used to other Kubernetes Components and related Projects. Reduces fan-out of multiple OSes or different versions of OSes across components. Potential benefits as to being able to obtain OS patches for vulnerabilities where Debian has decided only to fix in latest LTS (Debian 12) release and not older LTS releases.

Describe alternatives you've considered

Additional context

[kady1711]

Following up on the feature request for migrating external-provisioner to Debian 12 Distroless, I wanted to inquire about the progress and whether there is a targeted release date or version number for this migration.

This migration is crucial for aligning with the latest Kubernetes ecosystem developments and ensuring our deployments benefit from the security and maintenance advantages of Debian 12. It also aims to standardize the Container OS across Kubernetes components, reducing the complexity and potential security vulnerabilities associated with managing multiple OS versions.

Could you please provide an update on the status of this request? Knowing the planned release date or version would greatly assist in our planning and ensure we can align our deployments with the latest standards and practices.

[sdx-jkataja]

It appears the gcr.io/distroless/static:latest base image has already changed to Debian 12.
The change has taken place some time in between the versions:

• v4.0.1 is based on Debian 11
• v5.0.0 is based on Debian 12

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale