Add authorization for metrics endpoint

[sbueringer]

It would be great if controller-runtime would be able to authorize requests to the /metrics endpoint.

Some background information:

• Kubernetes core components protect the /metrics endpoint via authentication (user/group/SA) and authorization (via RBAC verb: get, nonResourceURLs: /metrics) (docs).
• The kube-rbac-proxy from @brancz can provide this functionality as a sidecar. (non-resource-url example)

It would be great to have this capability built into controller-runtime as it would make it possible to have this functionality without a dependency to an additional project and a sidecar container.

Is there interest in the controller-runtime community to support the nonResourceURL-based authorization (like core Kubernetes components)?

Notes:

• Not sure how other projects are handling this but in cluster-api we removed kube-rbac-proxy after a few lengthy disussions (I think main reason was that it's not community-owned, xref: ⚠️ Remove kube-rbac-proxy and expose metrics on localhost:8080 cluster-api#4640). Since then metrics are basically disabled per default in Cluster API since we also didn't want to expose them unauthorized per default for security reasons.
• ~ related the metrics endpoint should also be served on https instead of http (with the same cert as the webhook?)
• Not sure if other endpoints should be protected as well, but /metrics would be the most important one for us.

[sbueringer]

cc @alvaroaleman @joelanford @vincepri What do you think about it?

cc @fabriziopandini @killianmuldoon (given our recent discussions about metrics in Cluster API)

[alvaroaleman]

@sbueringer in general doing that seems ok to me but I also do not have a super precise picture of how much complexity this actually entails. From a cursory look at kube-rbac-proxy, most of the logic here can be imported from upstream?

[sbueringer]

Probably.

I'll try to get back to this as soon as I have time and implement a prototype or something so we have more data to decide this.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[sbueringer]

/remove-lifecycle stale

[sbueringer]

/assign