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.pull/10149/head
parent
9ff4313339
commit
949a1ff541
|
@ -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.
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue