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
Michael Schubert 2018-09-06 08:55:13 +02:00 committed by k8s-ci-robot
parent 9ff4313339
commit 949a1ff541
3 changed files with 5 additions and 2 deletions

View File

@ -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.

View File

@ -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>

View File

@ -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