-
Notifications
You must be signed in to change notification settings - Fork 204
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
path-based reboot mechanism #868
Comments
This issue was automatically considered stale due to lack of activity. Please update it and/or join our slack channels to promote it, before it automatically closes (in 7 days). |
Still relevant. |
This issue was automatically considered stale due to lack of activity. Please update it and/or join our slack channels to promote it, before it automatically closes (in 7 days). |
Would still be interesting. |
This issue was automatically considered stale due to lack of activity. Please update it and/or join our slack channels to promote it, before it automatically closes (in 7 days). |
This issue was automatically considered stale due to lack of activity. Please update it and/or join our slack channels to promote it, before it automatically closes (in 7 days). |
This issue just remained interesting. |
This issue was automatically considered stale due to lack of activity. Please update it and/or join our slack channels to promote it, before it automatically closes (in 7 days). |
Still nice to have. |
With my refactor it would be quite easy to achieve nowadays. These refactors are still ongoing. |
Following #814 , a reboot method option is being added which can be 'command' or 'signal'. Following an idea by @sftim #416 (comment) it would be natural to consider adding a 3rd option for reboot method, "path", which relies on systemd units on the node to trigger a reboot by writing to a path on the node. Third party security-focused admission controllers could be used to ensure that kured only has write access to an approved location, like /var/run/kured.
Disadvantage: requires admins to set up systemd units on the node out of band - though they may wish to anyway as this would also be a convenient way to do automated OS updates with a systemd timer. Kured could document recommended systemd unit files to install for this.
Advantage: The kured pod would not even need to have CAP_KILL or hostPID, so it would be as minimally privileged as possible.
The text was updated successfully, but these errors were encountered: