fixup! fixup! fixup! fixup! docs: add kube-rbac-proxy

content/Projects/Observability/kube-rbac-proxy.md

@@ -10,6 +10,8 @@ The purpose of `kube-rbac-proxy` is to distinguish between calls made by same or
 
 Both [OIDC JWT](https://github.com/brancz/kube-rbac-proxy/blob/52e49fbdb75e009db4d02e3986e51fdba0526378/pkg/authn/oidc.go#L45-L63) and [delegated (header-based)](https://github.com/kubernetes/apiserver/blob/8ad2e288d62d02276033ea11ee1efd94bb627836/pkg/authentication/authenticatorfactory/delegating.go#L102-L112) authentication rely on Bearer tokens to authenticate the requests. The tokens are validated against the OIDC provider or the Kubernetes API server, respectively. Monitoring components use [mTLS](#downstream-usage) for client-server authentication, which provides a secure way to establish trust based on each other's digital certificates. This token represents the identity of the user or service account that is making the request. A [`TokenReview` request is created](https://github.com/kubernetes/apiserver/blob/21bbcb57c672531fe8c431e1035405f9a4b061de/plugin/pkg/authenticator/token/webhook/webhook.go#L51-L53), and includes the bearer token that the client provided, which is then sent to the API server. The API server verifies the authenticity of the token and responds with the details of the authenticated party, if the operation was successful.
 
+Note that anonymous access is always disabled, and the proxy doesn't rely on HTTP headers to authenticate the request but it can add them if started with `--auth-header-fields-enabled`.
+
 ### [**Authorization**](https://github.com/brancz/kube-rbac-proxy/blob/1c7f88b5e951d25a493a175e93515068f5c77f3b/pkg/authz/auth.go#L31C1-L37)
 
 Once authentication is done, `kube-rbac-proxy` must then decide whether to allow the user's request to go through or not. A [`SubjectAccessReview` request is created](https://github.com/kubernetes/apiserver/blob/21bbcb57c672531fe8c431e1035405f9a4b061de/plugin/pkg/authorizer/webhook/webhook.go#L57-L59) for the API server, which allows for the review of the subject's access to a particular resource. Essentially, it checks whether the authenticated user or service account has sufficient permissions to perform the desired action on the requested resource, based on the RBAC permissions granted to it. If so, the request is forwarded to the endpoint, otherwise it is rejected. It is worth mentioning that the HTTP verbs are internally mapped to their [corresponding RBAC verbs](https://github.com/brancz/kube-rbac-proxy/blob/ccd5bc7fec36f9db0747033c2d698cc75a0e314c/pkg/proxy/proxy.go#L49-L60). Note that static authorization (as described in the [downstream usage](#downstream-usage) section) without SubjectAccessReview is also possible.
@@ -98,7 +100,7 @@ The following components use the same method in their `kube-rbac-proxy` configur
 
 For more details, refer to the `kube-rbac-proxy`'s [static authorization](https://github.com/brancz/kube-rbac-proxy/blob/4a44b610cd12c4cfe076a2b306283d0598c1bb7a/examples/static-auth/README.md#L169) example.
 
-For more information on collecting metrics in such cases, refer to the [metrics collection](https://rhobs-handbook.netlify.app/products/openshiftmonitoring/collecting_metrics.md/#kube-rbac-proxy-sidecar) section of the handbook.
+For more information on collecting metrics in such cases, refer to [this section](https://rhobs-handbook.netlify.app/products/openshiftmonitoring/collecting_metrics.md/#exposing-metrics-for-prometheus) of the handbook.
 
 On the other hand, the example below depicts restricted access to a resource, i.e., `monitoring.coreos.com/prometheusrules` in the `openshift-monitoring` namespace.