enable dependabot bumping of docker images

[upodroid]

key CI images are out of date, and I'm seeing a lot of CVEs reported by Datadog in our CI clusters.

https://us5.datadoghq.com/container-images?query=image_registry%3A%28gcr.io%20OR%20us-docker.pkg.dev%29&cols=name%2Ccontainer_count%2Csource%2Cvulns%2Ctag%2Crepo_digest%2Csize%2Cbuilt&sort=built

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: upodroid

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 [upodroid]

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

[BenTheElder]

key CI images are out of date, and I'm seeing a lot of CVEs reported by Datadog in our CI clusters.

Exploiting these isn't very interesting though, we provide RCE by design ... often as root on a disposable CI environment.

However, we do need to be careful about being able to patch other issues while not being blocked on breaking CI.

E.G. in the past bumping gcloud has broken the rather fragile kube-up.sh, we used to ask test-infra folks to keep an eye out when running upgrades and handle rollbacks.

This tower of tech debt stinks, but we all only have so much time to chip away at it.

I'm a little hesitant, generally I'm in favor of staying up to date, fully patched, etc, but these are primarily out of date not because sending a PR to bump them is hard, but because nobody wants to expend energy on dealing with failures at the moment and we have some fragile bits (e.g. also the dind in this repo is ... something we should improve and sensitive to docker updates) ...

[prad9192]

Hi @upodroid

I saw your note to pause on #35968

Could you also include the following updates? I noticed @BenTheElder’s comment as well, happy to help if anything comes up.

• https://github.com/upodroid/test-infra/blob/b0b3a5d77be7ed065746ca9be41232ad1c768eef/images/git-custom-k8s-auth/cloudbuild.yaml#L25-L26

_AWS_IAM_AUTHENTICATOR_VERSION: "0.7.9"
_AZURE_KUBELOGIN_VERSION: "0.2.13"

• https://github.com/upodroid/test-infra/blob/b0b3a5d77be7ed065746ca9be41232ad1c768eef/images/alpine/Dockerfile#L18

FROM alpine:3.22.2

[petr-muller]

I'm a little hesitant, generally I'm in favor of staying up to date, fully patched, etc, but these are primarily out of date not because sending a PR to bump them is hard, but because nobody wants to expend energy on dealing with failures at the moment and we have some fragile bits

I'd say let's set up the automation and reconsider if we start running into breaking things too much (and if we do maybe we could put some smoke tests in place to detect if a dep bump is safe?).

/lgtm
/hold

Changes LGTM so this hangs more on having high-level consensus that we want this

[petr-muller]

@upodroid do you want to address #35799 (comment) ?

[BenTheElder]

I'd say let's set up the automation and reconsider if we start running into breaking things too much (and if we do maybe we could put some smoke tests in place to detect if a dep bump is safe?).

We do pretty often with the CI images, for example I just fixed kubernetes/kubernetes#135575 yesterday ...

[upodroid]

/hold cancel

I'll open a separate PR to bump those deps and others.

[BenTheElder]

I'd say let's set up the automation and reconsider if we start running into breaking things too much (and if we do maybe we could put some smoke tests in place to detect if a dep bump is safe?).

We do pretty often with the CI images, for example I just fixed kubernetes/kubernetes#135575 yesterday ...

To elaborate ... the "api surface" of images like kubekins-e2e is enourmous, and smoke tests cannot cover them becasue there are so many ways they are being used by so many repos.

Unfortunately, relatively few people are participating in bugs like the one I linked previously, churning these dependencies doesn't buy us much but it does buy a lot of breakage.

As I mentioned previously, exploiting these images is ~irrelevant, you can just send us code and we'll run it ... and these images are not intended for end-users to reuse in production (or anywhere else), which is why they're not on registry.k8s.io