update the etcd base image to v1.4.2

[humblec]

The current base v1.3.0 has CVEs[1] which are addressed in latest versions of the bullseye image

[1] ex:
CVE-2022-2509
CVE-2021-46828

/kind cleanup

NONE

Additional note for reviewer:

The plan was to update the etcd docker file base image to v1.4.2, however the external dependencies check fails while we update only this part, so the base image version has been bumped to v1.4.2 in general. I am not sure, were there any specific reason to stick to v1.3.0 of bullseye in the dependencies.yaml and conformance test image.

[humblec]

/cc @ahrtr

[k8s-ci-robot]

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

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

In response to this:

/cc @ahrtr

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.

[humblec]

cc @jpbetz @serathius

[ahrtr]

Does it mean that K8s build etcd image itself instead of using etcd officially released image (e.g. gcr.io/etcd-development/etcd:v3.5.8)?

Currently etcd's base image is gcr.io/distroless/static-debian11, which should be much safer than bullseye. FYI. etcd-io/etcd#15016

[humblec]

cc @saschagrunert

[serathius]

Does it mean that K8s build etcd image itself instead of using etcd officially released image (e.g. gcr.io/etcd-development/etcd:v3.5.8)?

Yes, k8s uses etcd binaries, but rolls out it's own image with own scripting. For example they implement multi minor version upgrades. My work on etcdutl migrate was to replace tooling here https://github.com/kubernetes/kubernetes/tree/master/cluster/images/etcd.

Currently etcd's base image is gcr.io/distroless/static-debian11, which should be much safer than bullseye. FYI. etcd-io/etcd#15016

Yes, but k8s has its own backward incompatibility policies that are stricter than etcd. etcd just switched base image and even backport it (I was not a fan of that). Kubernetes community just cannot do this to it's user. That's maybe a reason why people prefer this image.

[serathius]

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 210f0e3c003881abb0f6e7d0620907ac2cd0c69a

[ahrtr]

Yes, k8s uses etcd binaries, but rolls out it's own image with own scripting.

thx for the clarification. Is the image only used for K8s's pipeline testing? Each cloud provider can choose etcd image or binary (e.g. use the etcd officially released binaries or images) themselves.

[serathius]

Yes, k8s uses etcd binaries, but rolls out it's own image with own scripting.

thx for the clarification. Is the image only used for K8s's pipeline testing? Each cloud provider can choose etcd image or binary (e.g. use the etcd officially released binaries or images) themselves.

It's treated more as an official K8s etcd image. As you said, each K8s distribution may pick etcd image as they want, however i think most of them pick this one. I think this is driven by misunderstanding of kubernetes-etcd compatibility. I have seen announcements "K8s now supports etcd v3.5" written based on fact that we bumped this image. You are right about the real purpose, this image is to test K8s code in CI and during releases.

[dims]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dims, humblec, serathius

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:

• build/OWNERS [dims]
• cluster/images/etcd/OWNERS [dims,serathius]
• test/conformance/image/OWNERS [dims]

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

[humblec]

/test pull-kubernetes-unit

[humblec]

/test pull-kubernetes-e2e-gce

[alexzielenski]

/triage accepted