-
Notifications
You must be signed in to change notification settings - Fork 179
Move own CA transport layer mtls guidance to security docs #3932
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 1 commit
4ef3fbb
3f5b433
c401bfa
c60da3e
b94310e
e43a868
60e11e0
74894f3
141c98d
59aaf4d
d6ecddf
fa7d774
b40ea3b
d2ff6e6
462feef
316536c
89ec319
404c1db
b683d4e
0566b5e
2468cc7
555c0f3
580e632
9cd7ad3
df3fe49
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,15 +20,17 @@ This page explains the requirements and best practices to ensure that certificat | |
| Transport connections between {{es}} nodes are security-critical and you must protect them carefully. Malicious actors who can observe or interfere with unencrypted node-to-node transport traffic can read or modify cluster data. A malicious actor who can establish a transport connection might be able to invoke system-internal APIs, including APIs that read or modify cluster data. | ||
| :::: | ||
|
|
||
| ## mTLS transport certificate requirements for external CAs | ||
| ## Transport mTLS certificate requirements for external CAs | ||
|
|
||
| Obtain your transport certificates from a certificate authority that only issues certificates to {{es}} nodes permitted to connect to your cluster. Do not use a public certificate authority or an organization-wide private certificate authority, because these issue certificates to entities beyond your authorized cluster nodes. Use a dedicated private certificate authority for each {{es}} cluster. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This first sentence should probably be considered or used for comparison in the section "Transport vs HTTP". We probably want to explain that this is not that relevant for HTTP, and for HTTP, for operational purposes (and because we have extra authentication and authorization mechanisms), it's common to not use dedicated CAs per cluster, and even public / organizational CAs that are automatically trusted by the clients. Of course this will depend on the use case, as in certain use cases it might have sense to have the HTTP layer also super-protected at TLS level. We should end up with the recommendation that as minimum, if they use private CAs, they should create a private CA to generate transport certs, and another private CA to generate HTTP certs. This relates with the comment in the "transport vs HTTP" section.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure what concrete change you're suggesting here. The title of this page is
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry if I wasn't clear enough @DaveCTurner , I wasn't suggesting a change there, just highlighting that the style and content of that first paragraph could be used in the section where we compare HTTP and transport. |
||
|
|
||
| Certificates used for mTLS must either have no Extended Key Usage extension, or include both `clientAuth` and `serverAuth` values in the extension. Public certificate authorities typically omit the `clientAuth` value in the Extended Key Usage extension, making them unsuitable for mTLS. | ||
| Certificates used for transport mTLS must either have no Extended Key Usage extension, or include both `clientAuth` and `serverAuth` values in the extension. Public certificate authorities typically omit the `clientAuth` value in the Extended Key Usage extension, making them unsuitable for mTLS. | ||
|
|
||
| ### Transport certificates vs. HTTP certificates | ||
|
|
||
| Transport certificates have different security requirements than [HTTP certificates](/deploy-manage/security/secure-cluster-communications.md#encrypt-http-communication). HTTP connections don't typically use mTLS because HTTP has its own authentication mechanisms. Because of this, HTTP certificates usually don't need to include the `clientAuth` value in their Extended Key Usage extension. HTTP certificates can come from public or organization-wide certificate authorities, while transport certificates should use a cluster-specific private CA. In most cases, you should not use the same certificate for both HTTP and transport connections. | ||
| Transport certificates have different security requirements than [HTTP certificates](/deploy-manage/security/secure-cluster-communications.md#encrypt-http-communication). HTTP server certificates don't require the `clientAuth` Extended Key Usage extension because they are used solely for server authentication, regardless of whether mTLS is enabled. In practice, HTTP connections don't typically use mTLS because HTTP has its own authentication mechanisms. | ||
|
|
||
| HTTP certificates can come from public or organization-wide certificate authorities, while transport certificates should use a cluster-specific private CA. In most cases, you should not use the same CA or certificate for both HTTP and transport connections. | ||
|
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. note "CA or certificate" here
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like it a lot, thanks!! |
||
|
|
||
| ## Turning off mTLS for transport connections [turn-off-mtls] | ||
|
|
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.