Improve --requestheader-client-ca-file warning
#10093
Conversation
k8s-ci-robot
added
cncf-cla: yes
|
Deploy preview for kubernetes-io-master-staging ready! Built with commit 52509b9 https://deploy-preview-10093--kubernetes-io-master-staging.netlify.com |
| @@ -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: make sure to use a distinct CA and do **not** reuse a CA that is used in a different | |||
There was a problem hiding this comment.
I don't think it's not absolutely necessary to use a different CA, but it is important to be careful about these certificates, no matter how they chain.
I would propose that this warning gets turned into a more general "this client certificate will be able to convey authentication info to the API server, so be careful with it."
And then down in the "--requestheader-allowed-names" description, we can call out that "any Common Name is allowed, which means that any client certificate issued by any CA in the bundle will be allowed."
There was a problem hiding this comment.
As far as I understand, the only way it can be secure with the same CA used for both --client-ca-file and --requestheader-client-ca-file is when absolutely all client traffic goes through the authenticating proxy (i.e. the apiserver is not reachable from other endpoints than the proxy and the --client-ca-file "not used"; I would guess that's a rare setup) or when --requestheader-allowed-names is chosen very carefully in combination with a procedure that makes sure that certificate signing requests with the allowed names are denied in general (i.e. do not kubectl certificate approve ... with a CN that matches one of those in --requestheader-allowed-names).
this client certificate will be able to convey authentication info to the API server, so be careful with it.
I'm worried that this is not clear. Expert users can always choose to make an educated decision against the general recommendation, but to me it seems the only "safe" general recommendation is to use a different CA.
"convey authentication info" is unclear about the actual impact (any client with a valid certificate can effectively escalate privileges to cluster admin). And "be careful" not actionable. What is the recommended, secure default? Where and how do I need to be careful? etc.
There was a problem hiding this comment.
Hmmm. Yeah, I see your point. Maybe we can go with the "don't do this" language, and just add a "unless you understand the risks and the mechanisms to protect the CA's usage."
WDYT?
There was a problem hiding this comment.
Sounds good to me, updated.
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.
schu
force-pushed
the
schu/more-explicit-requestheader-warning
branch
from
8e241cd to
52509b9
Compare
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cjcullen, tengqm The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
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.
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.