TD;DR - Is it considered safe to have a privileged container in a pod that is running in its own user namespace?
I’m using the hostUsers: false flag on a pod to run the pod in its own unprivileged user namespace. KEP-127 makes it clear that this can be used to safely add specific capabilities to containers, as can be evidenced by:
Allow pods to have capabilities (e.g. CAP_SYS_ADMIN) that are only valid in the pod (not valid in the host).
However, as far as I can tell, neither KEP-127 nor the k8s documentation on user namespaces mention the safety or repercussions of running a fully privileged container in this mode.
Thus my question… Is it considered safe to set privileged: true for a container that is in a pod running in its own user namespace?
Thanks a lot for any guidance or insight you can provide!
Being a non-root user is not enough to call anything secure at the host level. An attacker that gains user level access in the host’s namespace will have the ability to probe the real network, the internal interfaces, and gain more access through simple implementation mistakes. Even worse, imagine if you had an attacker that quietly infiltrates your system and waits until a new root escalation exploit is found. You end up in a situation where they will become root opportunistically before your routine patching cycle crops up.
To directly answer your TLDR question, no it’s not considered safe, but it’s also not wrong to use the feature if you take care to seal up cracks in your exposed surfaces if the worse case scenario happens.
In my opinion, this issue is related to the security team and not the concern of the DEVOPS team.
In Kubernetes, a privileged container is a container that has access to all host system resources, including kernel features and devices. By default, containers are not privileged and are limited to a subset of the host system’s resources.
When a pod is running in a user namespace, the container’s privileges are limited by the user’s namespace privileges. In particular, the container only has access to resources that are available in the user namespace. This means that a privileged container in a pod running in the user namespace will only have access to resources available in the user namespace, rather than all resources on the host system.
However, it’s important to note that running a privileged container in a pod can be a security risk, as it could potentially allow the container to access sensitive data or perform actions it shouldn’t be allowed to. Therefore, it is recommended to avoid running privileged containers in pods and instead use unprivileged containers with proper access control and security measures in place. If you need to run a premium container in a pod, you should carefully consider the potential risks and take appropriate precautions to secure the container and the host system.
The job title doesn’t matter. If your job has you tasked with being responsible for containerizing applications, you are also responsible for understanding the security implications of your design choices. It is dangerous to assume how broad someone’s role is, especially when a DevOps engineer at a startup might be wearing multiple hats.
Thank you @protosam and @jamallmahmoudi for your replies and insights. I basically agree with everything you said.
I think what your responses really showed me was that my question was poorly worded for what I am trying to understand. The answer to “is giving [some access] safe?” is almost always gonna be “no”, because by definition it’s less safe than not giving that access.
Had my question been “is it safe to give containers CAP_SYS_ADMIN in a pod running in a userns?”, the two replies above could have been given verbatim as legitimate responses to that question, because again it’s less safe than not giving that access. Yet both the KEP-127 documentation and the official k8s documentation on userns both mention the better security of running pods in user namespaces, citing many CVEs which are completely avoided by running in user namespaces.
So on second thought my real question is:
Which of these would you consider more of a security threat (larger attack surface, larger damage impact)?
A non-privileged container running in the default way (not isolated in a user namespace).
A privileged container running in a user namespace.