lock on a separate/safe object rather than DaemonSet

[anguslees]

Current locking approach requires the kured job to have the RBAC privilege to be able to update its own DaemonSet. This means a compromised kured job could redefine itself to (eg) elevate host access further(*).

Better (from an RBAC pov) would be to use a "harmless" resource type to store the lock annotation. A ConfigMap (empty/dedicated for this purpose) would be ideal.

(*) I acknowledge that kured also needs other scary privileges (patch nodes) in order to conduct a drain/uncordon, and these won't be improved by this suggestion. Small steps.

[awh]

Hi @anguslees - good thought, thanks. For other reasons I've been mulling introducing a kured CRD for a while, and that would make a good place to put the lock.

The node resource patching route is interesting - it's not immediately obvious to me how you could exploit that, any thoughts (other than just a plan denial of service attack I mean)?

[github-actions]

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).

[kfox1111]

still relevant.

[github-actions]

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).

[kfox1111]

still relevant.

[github-actions]

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).

[kfox1111]

still relevant.

[evrardjp]

Agreed.

[github-actions]

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).