In a previous article, we described how the usage of namespaces in Kubernetes significantly simplifies the management of a Kubernetes cluster. However, managing multiple microservices on the same cluster comes with a security cost when not planned correctly.
A common misconception around namespaces is that they are truly separated. However, it is more likely to think of it as a police tape—you know it is there, but it is fairly easy to bypass it.
In real life, this translates to a scenario when a newly created service ignores namespace segmentation by default, thus being exposed to other microservices running in the same cluster.
In this article, we will review several security risks when managing microservices with different security requirements (e.g. frontend and database) on the same cluster.
Is Kubernetes insecure by default?
While Kubernetes was originally designed without security tenancy and segmentation, it does have two important security mechanisms. The first one is RBAC (Role-Based Access Control). This mechanism matches users and service accounts to their allowed (or forbidden) actions on components, and basically manages the permissions on the cluster.
The second mechanism is Network Policy, which essentially acts as a firewall that manages traffic mostly inside the cluster. This mechanism is unlike a traditional enterprise firewall that manages traffic in and out of the perimeter network.
Infrastructure segmentation
When talking about container segmentation within nodes, we should start by explaining the Linux kernel namespaces concept, as containers use this kind of segmentation between one another. Although the name is ..
Support the originator by clicking the read the rest link below.
