Update kube-rbac-proxy to v0.8.0 release

[hectorj2f]

Per brancz/kube-rbac-proxy#99 (comment) has been pushed to quay.io/brancz/kube-rbac-proxy:v0.8.0. What is the process to update the gcr.io/kubebuilder/kube-rbac-proxy? Is this hand tagged and pushed by a maintainer?

Could you push it or retag it ? Thanks.

/kind bug

[camilamacedo86]

Hi @hectorj2f,

It has been done manually. @DirectXMan12 @vincepri @droot could you please give a hand with this one?

[hectorj2f]

Thanks @camilamacedo86.

[hectorj2f]

@DirectXMan12 @vincepri @droot Is there any way I could help with the release process/tagging for this new kube-rbac-proxy release 🙏🏻 ?

[camilamacedo86]

Hi @hectorj2f,

In the Kubebuilder, Controller Runtime, and Controller Tools meeting latest week we spoke about it. The current images built and pushed manually to gcr.io/kubebuilder/kube-rbac-proxy . And then, the author of https://github.com/brancz/kube-rbac-proxy has the intention to donate the project to k8s org, however, until it be done we need to automate it from the repo https://github.com/brancz/kube-rbac-proxy.

Currently has a little people with the requires access to push the images, so @DirectXMan12 would like to address it via automation instead of we still manually doing this work. @paulfantom, could you give a hand to us to achieve it?

So, far as a workaround, you can update your manager manifest yaml files to use the https://github.com/brancz/kube-rbac-proxy released images directly instead of it.

[camilamacedo86]

We need to the same that is done in https://github.com/brancz/kube-rbac-proxy/blob/master/.github/workflows/build.yml#L35-L42 to push the image to quay, however, to push the image to gcr.io/kubebuilder/kube-rbac-proxy

[camilamacedo86]

Just to register. We need to use the latest version of kube-rbac-proxy because the previous one is not rotless. More info: #1637

[hectorj2f]

@camilamacedo86 is there any update here ?

[camilamacedo86]

Hi @hectorj2f,

Unfortunately, I didn't have time to continue to see it. Would you like to help us with this one?
If yes, please feel free to ping me in the slack. However, the what we need to do here is to:

• Automate the building push to gcr.io/kubebuilder/kube-rbac-proxy when a new tag release is pushed in the *: cut v0.8.0 brancz/kube-rbac-proxy#99. See: https://github.com/brancz/kube-rbac-proxy/blob/master/.github/workflows/build.yml#L35-L42
• After we have a new image in gcr.io/kubebuilder/kube-rbac-proxy we can update the scaffolds.

[hectorj2f]

@camilamacedo86 I'd check what I can do ;), to speed things and get this done asap.

[camilamacedo86]

just to register here: Why it is important we have the latest release for and update the kubebuilder scaffolds to use it as soon as possible?

The latest images contain a fix brancz/kube-rbac-proxy#86 to make the images rootless to solve critical security concerns. More info: #1637. So, I am setting its milestone as 3.1.0.

c/c @estroz @DirectXMan12 @droot

[shysank]

@hectorj2f did you get a chance to look into building the latest kube-rbac-proxy image? We also share similar concerns in kubernetes-sigs/cluster-api. Happy to pick it up if you're not working on it.

/cc @vincepri

[camilamacedo86]

@estroz this is the task. Based on the meeting feel free to assign it to yourself.

[estroz]

/assign

[hectorj2f]

Thanks @estroz

[sdeoras]

my arm64 based k8s cluster complained that it could not detect platform in the manifest when pulling from gcr, however, changing to quay.io/brancz, things worked fine. I am wondering if arm64 is supported for this container image on gcr?

[estroz]

I think our gcr.io/kubebuilder/kube-rbac-proxy build did not build or pull images for the arch set properly.

What's weird is docker run --rm quay.io/brancz/kube-rbac-proxy:v0.6.0-s390x on an amd64 machine works (the code runs and panics because of application logic, not instruction set incompat), when it shouldn't.

[sdeoras]

thanks for looking into it @estroz . yeah, i see all four items in the manifest show amd64 as arch. should i file a bug for it?

[DirectXMan12]

EDIT: this is a red herring, @estroz is correct above in the source images being weird, but we prob still want to fix this eventually

EDIT x2: the plot thickens

Looks like docker manifest rm is erroring out as not a subcommand of docker manifest:

<snip>
Status: Downloaded newer image for quay.io/brancz/kube-rbac-proxy:v0.8.0-s390x
quay.io/brancz/kube-rbac-proxy:v0.8.0-s390x
The push refers to repository [gcr.io/kubebuilder/kube-rbac-proxy]
144603524578: Preparing
fd6fa224ea91: Preparing
144603524578: Layer already exists
fd6fa224ea91: Layer already exists
v0.8.0-s390x: digest: sha256:257deb7abac3138fb5497cddd3bc85b14d9de5188f6cfe70e0e0c7c4741583a6 size: 739

Usage:	docker manifest COMMAND

The **docker manifest** command has subcommands for managing image manifests and
manifest lists. A manifest list allows you to use one name to refer to the same image
built for multiple architectures.

To see help for a subcommand, use:

    docker manifest CMD --help

For full details on using docker manifest lists, see the registry v2 specification.

Commands:
  annotate    Add additional information to a local image manifest
  create      Create a local manifest list for annotating and pushing to a registry
  inspect     Display an image manifest, or manifest list
  push        Push a manifest list to a repository

Run 'docker manifest COMMAND --help' for more information on a command.
Created manifest list gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0
sha256:a06e7b56c5e1e63b87abb417344f59bf4a8e53695b8463121537c3854c5fda82
ERROR
ERROR: failed to find one or more images after execution of build steps: ["gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0"]

[DirectXMan12]

update: it turns out we weren't annotating the manifests properly (see above PR). IDK what's up with @estroz's docker though