-
Notifications
You must be signed in to change notification settings - Fork 102
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
Reload Configuration on Signal #191
Comments
Yeah, reloading makes sense. I think the Unix way is to respond to a sighup, right? |
Indeed, if that would be implemented it would play very very well along with: https://github.com/spiffe/spiffe-helper#readme as it's process wrapper / reload manager. If somebody could lend a hand with this in the coming days it would be a perfect coordination of efforts. 😉 |
How often does certificate rotation occur? The way that occurs to me to implement it would probably incur some downtime:
We're actually in the middle of a refactoring that will replace the underlying framework, so it might be an idea to complete that before moving to this task. |
I'm going to give this a more generic title, as I think we should be able to handle reloading all config. |
Spire default is every 5 minutes, but it's configurable and users are expected to tweak as to strike a good balance between their security requirements and service performance. I think reloading the whole server with downtime is relatively straight forward. I've done exactly this for other solutions, that do not support certificate reloading. Though, I don't think it fits for a canonical implementation. There has even been a discussion on OpenSSL mailing list about the topic. https://www.mail-archive.com/[email protected]/msg88596.html The conclusion was more or less:
|
Thanks. The trouble is that's pretty low-level stuff, and I'm not sure how much I can control it with the current frameworks. It does also bring up an alternative solution - monitoring the cert file and automatically reloading if it changes. If it is easily possible to "keep running contexts around" that may be a better solution, but I'm still leaning towards using signals (which implies a restart and complete config reload). |
I came to the conclusion, that if time and budget is to be spent on this issue, it ultimately should be made available upstream: rwf2/Rocket#1448 It looks as if this is the rocket frameworks implementation of tls. I kind of get it, first time reading rust code, though. |
I've setup a testbed here: #193 |
Is your feature request related to a problem? Please describe.
For implementing #184 , I need a way to instruct trow to geacefully reload it's certificates and accept new connections on a new ssl contexts.
Describe the solution you'd like
Since rollover is done well ahead of certificate TTL (at roughly 80%), no urgency is at hand which is while current connection can be normally phased out.
It is not necesary for trow to detect those changes, although this is a possibility, should it be easier to implement. Probably not, since safeguards would have to be put in place to avoid race conditions while reloading the different files.
Rather the most portable solution appears to be exposing a configuration api stub, which induces a reload of the TLS context from disk upon trigger (eg. POST). Maybe something simple and similar to the healthcheck endpoints can be conceived or alternativle a special configuration port that would not be exposed outside of the pod context for some basic shielding.
Describe alternatives you've considered
Kill & restart. Does imply service interruptuons.
Additional context
The text was updated successfully, but these errors were encountered: