⚠️ 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! 🙏

[alegacy]

We need to evaluate the impact on our plans to support future ORAN security requirements. Using a RH image may be preferable to using the WithAuthenticationAndAuthorization handler depending on how well that meets the upcoming requirements.

[donpenney]

Updating to use quay.io/openshift/origin-kube-rbac-proxy:4.18 for now

[camilamacedo86]

Hi @alegacy,

I can see that you are using kubebuilder: GitHub Link.
I suggest waiting for the next release of the tool and upgrading your project.

You can run kubebuilder generate to re-scaffold everything and just add your code on top.

This will also enable the feature to provide certificates for WithAuthenticationAndAuthorization and make your project production-ready. Currently, using kube-rbac-proxy with WithAuthenticationAndAuthorization without certificates is not ideal for production. See my PR adding this feature: PR #4400. The goal is to have it done in the next release.

However, if you do not want to fully upgrade, then you can move with a similar approach now. If you have questions, please feel free to reach out.

But WithAuthenticationAndAuthorization is a better option:

• Eliminates the need for the deprecated kube-rbac-proxy image, reducing complexity.
• Ensures updates, bug fixes, and improvements in Controller-Runtime are naturally integrated.
• Reduces risks by removing dependency on external images like kube-rbac-proxy.
• Minimizes extra checks for updates or compatibility, streamlining development workflows.

The only downside that I hope will soon be addressed is tracked in: kubernetes-sigs/controller-runtime#2781. We need to improve it to add /healthz endpoint on the metrics server and add support for alwaysAllow paths (e.g., /healthz) and alwaysAllowGroups (e.g., system:masters) to prevent metrics outages during kube-apiserver networking issues, ensuring availability during critical times.

[alegacy]

@camilamacedo86 Looks like this is specifically targeted to only handle the authn/authz for the metrics endpoint. While we do have some use cases where this can be implemented using the method provided (i.e., on the metrics endpoint of our operator) we have other use cases where this won't be possible -- or at least doesn't appear to be a simple drop-in replacement.

For instance, we currently use the kube-rbac-proxy to do authn/authz for non-metrics API endpoints which are implemented by our microservices. These are not metrics endpoints. These are application level API endpoints. We currently use kube-rbac-proxy to protect those rather than owning more code to implement that functionality directly in our microservices.

Yes, it would be possible to write those handlers in a similar way as the filters.WithAuthenticationAndAuthorization and have them work for our non-metrics API endpoints, but we do anticipate needing to leverage the OIDC capabilities of the existing kube-rbac-proxy functionality to secure our application using an external OIDC authentication server.

Again, yes, we could write custom handlers to do that but short of a ready-to-go drop-in replacement we'd have to duplicate and own code that already exists in kube-rbac-proxy.

Is there a ready-to-go library implementation that we could use that would instantiate an HTTP middleware filter (e.g., func(http.Handler) http.Handler) capable of doing OIDC to an external OIDC server?

[camilamacedo86]

Hi @alegacy

However, the most important here is that you cannot use the upstream image gcr.io/kubebuilder/kube-rbac-proxy; any version of this project using it will be impacted when the image disappears. That means your solution will not work at all (unless the image is found in the node cache or it is running in a cluster with all mirrored)

The feature in the controller runtime seems like target authentication and authorization primarily for metrics endpoints. You can raise an RFE there or look for alternatives. But if you are happy with the kube-rbac-proxy solution and it already provides what you need, you might stick with it. However, unfurtunilly, you can no longer use the image from this Registry.

If you already replaced used it from another place (at your own risk) and are happy with please feel free to close this one.