Security hardening for kured

[saschagrunert]

I think we should work on security hardening for the kured DaemonSet and maybe the application itself. It runs as privileged container which seems a more general security issue from my point of view:

skuba/internal/pkg/skuba/addons/kured.go

Line 158 in 1967cc7

privileged: true # Give permission to nsenter /proc/1/ns/mnt

The Weaveworks community is already aware of the issue and I would suggest:

• Contribute to kured that we do not need to run it as privileged container any more (see security hardening kubereboot/kured#60)
• Wrap-up a seccomp/AppArmor profile for kured to further security harden from a k8s perspective

WDYT?

[flavio]

I would be super happy to see us help here! 🚀

[saschagrunert]

I think this would be a good opportunity for someone who wants to start contributing to upstream, especially because it’s important but not urgent. I’m happy to help with anything and leave this issue open for now. 😊

As background information, we found this issue by working on the seccomp-operator and evaluating possible applications where we could apply default profiles. Kured seems a good start and the profile could be contributed to the operator as well. This way we could simply utilize the operator later on to deploy default profiles in our products and in the wild. 😜

[jenting]

The kucero also have this issue.

[evrardjp]

I am happy to contribute there, as I already am. However, I am not sure how we can avoid that, as we need to access host though.

[saschagrunert]

I am happy to contribute there, as I already am. However, I am not sure how we can avoid that, as we need to access host though.

Paulo is working on a possible solution in kubereboot/kured#172. If that’s a feasible way then we can adapt our deployment too. 🙂