⚠️ Action Required: Replace Deprecated gcr.io/kubebuilder/kube-rbac-proxy

[camilamacedo86]

Description

⚠️ The image gcr.io/kubebuilder/kube-rbac-proxy is deprecated and will become unavailable.
You must move as soon as possible, sometime from early 2025, the GCR will go away.

Unfortunately, we're unable to provide any guarantees regarding timelines or potential extensions at this time. Images provided under GRC will be unavailable from March 18, 2025, as per announcement. However, gcr.io/kubebuilder/may be unavailable before this date due to efforts to deprecate infrastructure.

• If your project uses gcr.io/kubebuilder/kube-rbac-proxy, it will be affected.
  Your project may fail to work if the image cannot be pulled. You must take action as soon as possible.

• However, if your project is no longer using this image, no action is required, and you can close this issue.

Using the image gcr.io/kubebuilder/kube-rbac-proxy?

kube-rbac-proxy was historically used to protect the metrics endpoint. However, its usage has been discontinued in Kubebuilder. The default scaffold now leverages the WithAuthenticationAndAuthorization feature provided by Controller-Runtime.

This feature provides integrated support for securing metrics endpoints by embedding authentication (authn) and authorization (authz) mechanisms directly into the controller manager's metrics server, replacing the need for (https://github.com/brancz/kube-rbac-proxy) to secure metrics endpoints.

What To Do?

You must replace the deprecated image gcr.io/kubebuilder/kube-rbac-proxy with an alternative approach. For example:

• Update your project to use WithAuthenticationAndAuthorization:

  You can fully upgrade your project to use the latest scaffolds provided by the tool or manually make the necessary changes. Refer to the FAQ and Discussion for detailed instructions on how to manually update your project and test the changes.

• Alternatively, replace the image with another trusted source at your own risk, as its usage has been discontinued in Kubebuilder.

For further information, suggestions, and guidance:

• 📖 FAQ and Discussion
• 💬 Join the Slack channel: #kubebuilder.

NOTE: This issue was opened automatically as part of our efforts to identify projects that might be affected and to raise awareness about this change within the community. If your project is no longer using this image, feel free to close this issue.

We sincerely apologize for any inconvenience this may cause.

Thank you for your cooperation and understanding! 🙏

[AObuchow]

Maybe as an easy drop-in replacement, we could use https://catalog.redhat.com/software/containers/openshift4/ose-kube-rbac-proxy/5cdb2634dd19c778293b4d98 or https://catalog.redhat.com/software/containers/openshift4/ose-kube-rbac-proxy-rhel9/652809a5244cb343fb4a4b66 (which we are using for DWO downstream)?

[camilamacedo86]

Hi @AObuchow,

Using Red Hat images is a valid approach if you plan to distribute this solution only to users who have access to the registry to pull the image and can comply with its terms and conditions. IMPORTANT: Check its terms and conditions and know if you can really use that.

That said, the best approach would be to leverage the feature provided by controller-runtime and, for production environments, ensure that certificates are properly configured. This would be my recommendation.

Avoid relying on extra dependencies unless absolutely necessary, and try not to depend on any specific registry unnecessarily.

Let me know your thoughts!

[ibuziuk]

@dkwon17 @tolusha we should probably do what we have done for the image-puller - che-incubator/kubernetes-image-puller-operator#162