-
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
Support reloading TLS configuration #4204
Conversation
Implementation is based heavily on similar functionality in Nomad. hashicorp/nomad#3479
Current code is worth looking at. I'm looking into the failing tests. Please let me know if changes are required. If the implementation looks fine, I'll add the remaining features and tests. |
This brings back the default TLS configuration used for checks when agent TLS is disabled for checks. Fixes incorrect TLS configuration for https checks.
Adds the missing configuration fields in the TLS config.
This is normally added with http2.ConfigureServer. Since that modifies the server configuration in-place, and we override the configuration when using the callback, we have to supply it ourselves.
So sorry to have left this without a response this long - I was sure I had responded a while back. Firstly, thanks for this contribution - it looks really good and is certainly a highly demanded improvement. Our main issue with merging it as is are:
Apologies to many folks waiting on this feature or who tried this PR and it solves their problem - we really want to balance getting this improved with the wider plans for Consul. Adding this before we've had time to fully design the above risks introducing behaviour/config that's not exactly what we need but would be re-written or even becomes a breaking change to replace in a few months. |
@akshayganeshen thanks a lot for you work! I reviewed your PR and it certainly does what it says it is doing! Consul uses the agent TLS config in many more places though which you did not cover. I started working on that based on your PR, but that was just too much work. Before we can start working on reloading TLS config, we need to centralise it. I am working on that now, and reloading afterwards. Thanks again! |
Features
"key_file"
, and"cert_file"
and/or underlying files)"ca_file"
/"ca_path"
and/or underlying files)"verify_incoming"
, and"verify_outgoing"
)"enable_agent_tls_for_checks"
)"node_name"
/"server_name"
)"tls_min_version"
,"tls_cipher_suites"
, and"tls_prefer_server_cipher_suites"
)Still TODO
Use-cases
Reload short-lived/automated certificates without downtime. See #2584.
Design
The design is based around a
Loader
object that supplies TLS configuration dynamically via callbacks. This is similar to theKeyLoader
approach used in Nomad (see this pr).The
Agent
holds a reference to theLoader
instance that generates TLS configurations for both incoming and outgoing connections. During agent reload, the new configuration is passed to theLoader
, which is subsequently used for any new connections.Implementation
The
Loader
sets up the callbackGetConfigForClient
to provide atls.Config
for each incoming connection.When calling
Reload
, theLoader
pre-calculates the incoming and outgoingtls.Config
and returns them as appropriate.Questions
SessionTicketKey
that I don't fully understand.Loader
be a part ofAgent
? I wanted to avoid modifyingRuntimeConfig
, but I'm not sure if there is a better place to put it.