Improve --requestheader-client-ca-file warning (#10093)

It's important to use a distinct CA (unless you exactly know what you
are doing) but not clear from the current documentation and warning.

content/en/docs/reference/access-authn-authz/authentication.md

@@ -548,7 +548,8 @@ extra:
 
 In order to prevent header spoofing, the authenticating proxy is required to present a valid client
 certificate to the API server for validation against the specified CA before the request headers are
-checked.
+checked. WARNING: do **not** reuse a CA that is used in a different context unless you understand
+the risks and the mechanisms to protect the CA's usage.
 
 * `--requestheader-client-ca-file` Required. PEM-encoded certificate bundle. A valid client certificate must be presented and validated against the certificate authorities in the specified file before the request headers are checked for user names.
 * `--requestheader-allowed-names` Optional.  List of common names (cn). If set, a valid client certificate with a Common Name (cn) in the specified list must be presented before the request headers are checked for user names. If empty, any Common Name is allowed.

content/en/docs/reference/command-line-tools-reference/kube-apiserver.md

@@ -759,7 +759,7 @@ kube-apiserver [flags]
       <td colspan="2">--requestheader-client-ca-file string</td>
     </tr>
     <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: do **not** reuse a CA that is used in a different context (for example with --client-ca-file) unless you understand the risks and the mechanisms to protect the CA's usage. Generally it is recommended to not depend on authorization being already done for incoming requests.</td>
     </tr>
 
     <tr>

content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md

@@ -38,6 +38,8 @@ Enable the aggregation layer via the following kube-apiserver flags. They may ha
     --proxy-client-cert-file=<path to aggregator proxy cert>
     --proxy-client-key-file=<path to aggregator proxy key>
 
+WARNING: do **not** reuse a CA that is used in a different context unless you understand the risks and the mechanisms to protect the CA's usage.
+
 If you are not running kube-proxy on a host running the API server, then you must make sure that the system is enabled with the following apiserver flag:
 
     --enable-aggregator-routing=true