feat: use multi arch supported image for kube-rbac-proxy.

[ashokpariya0]

The origin-kube-rbac-proxy image is not compatible with the s390x architecture. This change deploys an image that is multi arch supported.

What this PR does / why we need it:
The origin-kube-rbac-proxy image is not compatible with the s390x architecture.
This change deploys an image that is multi arch supported(https://quay.io/repository/brancz/kube-rbac-proxy/manifest/sha256:e6a323504999b2a4d2a6bf94f8580a050378eba0900fd31335cf9df5787d9a9b).

Special notes for your reviewer:
proposed image(https://quay.io/repository/brancz/kube-rbac-proxy/manifest/sha256:e6a323504999b2a4d2a6bf94f8580a050378eba0900fd31335cf9df5787d9a9b) is built from parent repo of https://github.com/openshift/kube-rbac-proxy.

Release note:

None

[kubevirt-bot]

Hi @ashokpariya0. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

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-sigs/prow repository.

[oshoval]

/lgtm

Thanks

Please ref the issue, so Ram can see all the discussion there, because he is the maintainer of KMP

[ashokpariya0]

@RamLavi For your reference Issue.

[RamLavi]

/lgtm
/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RamLavi

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

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

[RamLavi]

@ashokpariya0 do you need this bumped to CNAO?

[oshoval]

@ashokpariya0 do you need this bumped to CNAO?

done already thanks
it doesnt need a release
it is done in other means kubevirt/cluster-network-addons-operator#1917
since this image also used by CNAO itself it has other flow

[RamLavi]

@ashokpariya0 do you need this bumped to CNAO?

done already thanks it doesnt need a release it is done in other means kubevirt/cluster-network-addons-operator#1917 since this image also used by CNAO itself it has other flow

ACK.
Then perhaps we should bump CNAO on kmp then?

[oshoval]

@ashokpariya0 do you need this bumped to CNAO?

done already thanks it doesnt need a release it is done in other means kubevirt/cluster-network-addons-operator#1917 since this image also used by CNAO itself it has other flow

ACK. Then perhaps we should bump CNAO on kmp then?

if KMP uses CNAO then yes for the CNAO image part (but not for itself), if it doesnt then no need
well the fact it is there maybe means it does use it