-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Only require verify_incoming_rpc for auto_encrypt.allow_tls #6376
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm a little confused (perhaps it's just the naming?) as to why this is necessary. Intentionally disabling verification (is this verifying that requests are coming from a shared CA in Consul cluster?) of all incoming HTTPS requests just to serve the UI seems undesirable and maybe opening a vulnerability?
Would it be possible/desirable instead to only allow incoming requests to the UI to ignore verification instead of disabling it entirely? Very possible I'm not fully understanding what's going on here though 😄
I'm trying to configure the UI for HTTPS which requires setting
verify_incoming
to false andverify_incoming_rpc
to true.
#6127 (comment)
@mikemorris good questions! AutoEncrypt works via RPC and technically it doesn't require
Yes.
Yes. It means that HTTPS requests to that particular agent's HTTP API are not required to provide a client cert that was signed by the shared CA.
It would be better indeed if that would be possible, but it is not at this point. And in general I am more inclined to remove knobs that tune security and go to secure by default. I thought about the UI before and in my mind the problem is that we share the same CA/certs for RPC, HTTPS, and serving the UI. If these things would be separate it would be easier to reason about. If there would be a separate CA/cert for the UI we could even allow letsencrypt possibly. But thats not an option if the same cert is used for RPC as well. If you want to read more about how to enable the HTTPS UI, you can go here: https://learn.hashicorp.com/consul/security-networking/certificates#configuring-the-consul-ui-for-https. I think it explains pretty well how the system works right now. Not saying this is a great way by any means though. :) Does that clarify things? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about the UI before and in my mind the problem is that we share the same CA/certs for RPC, HTTPS, and serving the UI.
Separating the UI to be able to use its' own cert (including something like letsencrypt) rather than being linked to internal cluster settings feels like a good direction for future work. 👍
If you want to read more about how to enable the HTTPS UI, you can go here: https://learn.hashicorp.com/consul/security-networking/certificates#configuring-the-consul-ui-for-https.
I think the details I was missing were the suggested config below to be used in conjunction with "verify_incoming": false
and the note that this is to be configured manually for 1-2 agents, not everywhere in something like central config... (although this feels potentially too easy for an operator to misconfigure)
"enable_script_checks": false,
"disable_remote_exec": true
Otherwise it is impossible to host the UI on a server node while using
auto_encrypt
. Fixes #6338.