From 949a1ff541a2a266d064f0b1a735a15f3cc2cf8f Mon Sep 17 00:00:00 2001 From: Michael Schubert Date: Thu, 6 Sep 2018 08:55:13 +0200 Subject: [PATCH] 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 | 3 ++- .../reference/command-line-tools-reference/kube-apiserver.md | 2 +- .../tasks/access-kubernetes-api/configure-aggregation-layer.md | 2 ++ 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index 861f6cd579..83e9caeb56 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/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. diff --git a/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md b/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md index 2a9f0ce66b..da2e787ffc 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md @@ -759,7 +759,7 @@ kube-apiserver [flags] --requestheader-client-ca-file string - 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. + 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. diff --git a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md b/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md index 36d798fd64..94dcf020e9 100644 --- a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md +++ b/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= --proxy-client-key-file= +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