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

Co-authored-by: Simon Pasquier <spasquie@redhat.com>

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

@@ -57,13 +57,6 @@ spec:
         - "--tls-private-key-file=/etc/tls/private/tls.key"
         - "--client-ca-file=/etc/tls/client/client-ca.crt"
         ...
-        volumeMounts:
-        - name: secret-volume
-          mountPath: /etc/tls
-      volumes:
-      - name: secret-volume
-        secret:
-          secretName: kube-rbac-proxy
 ```
 
 CMO specifies the aforementioned CA certificate in the [metrics-client-ca](https://github.com/openshift/cluster-monitoring-operator/blob/6795f509e77cce6d24e5a3e371a432ca22e1a8e7/assets/cluster-monitoring-operator/metrics-client-ca.yaml) ConfigMap which is used to define client certificates for every `kube-rbac-proxy` container that's safeguarding a component. The component's `Service` endpoints are secured using the generated TLS `Secret` annotating it with the `service.beta.openshift.io/serving-cert-secret-name`. Internally, this requests the [`service-ca`](https://access.redhat.com/documentation/en-us/openshift_container_platform/4.1/html/authentication/configuring-certificates#understanding-service-serving_service-serving-certificate) controller to generate a `Secret` containing a certificate and key pair for the `${service.name}.${service.namespace}.svc`. These TLS manifests are then used in various component `ServiceMonitors` to define their TLS configurations, and within CMO to ensure a "mutual" acknowledgement between the two.