security hardening about kured

[adhodgson1]

In addition I am wondering whether we could tighten up the privileged container access by removing some of the unneeded Linux capabilities to help reduce the scope of the container?

[arianmotamedi]

There hasn't been any activity on this in a while but do we know what the minimum set of requirements for the container to run are? Ideally we shouldn't have to run it as root.

[bboreham]

@kfox1111 no plans to add a separate service in this project.
Making the locked object independent of the daemonset seems like a good idea - could be a runtime parameter?

[evrardjp]

I think this might be partially linked to #25

[evrardjp]

I have a PoC code that uses the NodeRestriction Admission controller [1], but sadly I had to map the host's kubelet conf and certs into the container, which means that it probably has more access than before... (secrets?). So that's probably not a good idea.

Does anyone have a better idea, that doesn't involve writing a new service/operator?

1: evrardjp@18eb857

[kfox1111]

That still sounds like it has better security then the existing solution. In the existing solution, you already have access to all the node's secrets as you can just tweak the deployment to give your pod access to the whole nodes filesystem. You can also tweak the deployment to give you access to other secrets in the same namespace it may not already have access to.

Long term, I'd like to see an option to restrict service accounts to nodes using the NodeRestriction Admission controller. This problem is not specific to kured, but csi drivers, cni drivers, some monitoring plugins, logging, etc all suffer from this same issue. This will need a KEP in Kubernetes.

[evrardjp]

Totally agreed on the last bit.

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