bundle: remove usage of kube-rbac-proxy image

[iamniting]

kube-rbac-proxy image is deprecated. We wont be able to pull it from
early 2025 as gcr.io/kubebuilder will be unavailable.

Protect metrics endpoint with WithAuthenticationAndAuthorization method.

Ref:
kubernetes-sigs/kubebuilder#3907
red-hat-storage/ocs-operator#2912

Signed-off-by: Nitin Goyal nigoyal@redhat.com

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: iamniting

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

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

[iamniting]

cc @camilamacedo86

Can you pls take a look once?

[camilamacedo86]

You remove the image but you did not added the code to protect your metrics
Now, it is not protected at all. You must ensure that it is protected

please see: Check out the FAQ section: "How can I manually change my project to switch to Controller-Runtime's built-in auth protection?" for detailed instructions.**

[iamniting]

I did in the first commit. I used the WithAuthenticationAndAuthorization method. I have not added the service because it was already included here.

https://github.com/red-hat-storage/odf-operator/blob/main/config/rbac/auth_proxy_service.yaml

[camilamacedo86]

OH I see here: https://github.com/red-hat-storage/odf-operator/pull/514/files#diff-2873f79a86c0d8b3335cd7731b0ecf7dd4301eb19a82ef7a1cba7589b5252261R106-R111

Sorry for the false alarm !!!!

Great !!

One thing to remember for a follow-up PR is to check if you cannot provide certs for the Metrics Server. It would be recommended to ensure security. See an example of the PR to introduce a helper in the next release: kubernetes-sigs/kubebuilder#4400

[iamniting]

Do we need these certs if we are only running in the OCP environments? Just the annotations are enough right?

[camilamacedo86]

Ideally, yes, you should provide your own certificates, regardless of whether you're running exclusively on OCP.

The reason for this is that if you don’t explicitly specify the certificates, the implementation in controller-runtime (or previously in rbac-kube-proxy) will generate them for you. However, these are typically self-signed certificates, which are not suitable for production environments.

That said, OpenShift (OCP) provides a solution for generating and managing certificates through an operator. With the changes introduced in this PR, you maintain the same level of protection as before, so you're good to proceed within its scope.

However, I would recommend tracking an issue or initiating an effort to evaluate OCP's certificate generation solution and pass it here. That is a very simple change after, you will only need to do something like

		if len(certDir) > 0 {
			setupLog.Info("using certificates for the metrics server",
				"cert-dir", certDir, "cert-name", certName, "cert-key", certKey)

			var err error
			certWatcher, err = certwatcher.New(filepath.Join(certDir, certName), filepath.Join(certDir, certKey))
			if err != nil {
				setupLog.Error(err, "to initialize certificate watcher", "error", err)
				os.Exit(1)
			}

			metricsServerOptions.TLSOpts = append(metricsServerOptions.TLSOpts, func(config *tls.Config) {
				config.GetCertificate = certWatcher.GetCertificate
			})
		}