Search code examples
securitykubernetesnamespaceslog4jkubernetes-networkpolicy

Can one namespace with compromised log4j versions deployed "infect" an entire Kubernetes cluster?


I am dealing with a fairly simple question.

Assume we have a Kubernetes cluster and several namespaces (say, default, monitoring, A, B, C). These namespaces are logically separated from one another via NetworkPolicies. That means, A cannot see what is going on in default, monitoring, B, C. Analogous things can be said about B and C.

However, monitoring and default can see what is going on in all namespaces.

Now someone deploys some "rogue resources" in one of the namespaces A, B, and C, say, A. Here I mean a deployment with a compromised version of log4j. Of course, that is bad for everything in namespace A.

My question is now: Does that also affect negatively resources in default, monitoring, B, C or are they completely unharmed?


Solution

  • Namespaces are a way to organize clusters into virtual sub-clusters — they can be helpful when different teams or projects share a Kubernetes cluster. Any number of namespaces are supported within a cluster, each logically separated from others but with the ability to communicate with each other.

    So if any of the namespace is compromised or has an infected component which is exploited to allow say for example a RCE or a reverse shell , the compromised namespace is now acting like a gateway for the remote attacker and can be easily used as a launch pad against other resources not only in the same namespace but in other namespaces as well. So yes it negatively impacts and increases the RISK for other namespaces.