Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Obviously CAP_SYS_ADMIN and root-running containers should be avoided.

But on the occasion that they're necessary, isolating from other pods with a network policy and having no public ingress is enough right?

Assuming of course that you trust the container process(es) - or is that the issue?



I'd say "that depends"

For example if you're running Kubernetes, then if you have a user who has RBAC rights to exec into a privileged pod, but doesn't have rights to create new privileged pods, then this could be a privesc risk, as they can use something like this to escalate to the underlying node after exec'ing into the privileged pod.

It (as with all things security) depends on your threat model :)


Good point - I was thinking that 'operators' were trusted though, potential threat is the (ab)users of the running software.

As far as I can tell, as long as there is no service/ingress on the privileged container, and a netpol blocks those that do from accessing it, it's less than ideal but 'ok' that this privileged container is running behind the scenes.


AFAIK, that's the only what to run Chrome unless you disable Chrome's sandboxing.


Lateral movement of an attacker within your cluster would also be a problem.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: