Kubernetes namespaces – they’re an essential feature for building modern cloud architectures. Namespaces let you split up a single cluster into multiple “virtual clusters”. Resources like pods, replicasets, and deployments all live in namespaces. You can think of a namespace as being a resource’s last name – it specifies which family the resource is part of – and normal resources can have one and only one namespace (There are exceptions like the Node resource which is cluster-wide and doesn’t belong to any namespace). If you don’t think you’re using namespaces on your cluster then you’re wrong. You’re actually just putting everything into the default namespace.
Despite the widespread popularity of namespaces, there are actually several very different ways that namespaces are being used in real-world Kubernetes clusters. Here are some of the most common ways of using namespaces.
Namespaces for Multi-tenant Environments
Imagine that you work for a SaaS company with one very big customer. You run all the infrastructure for that customer on a dedicated K8s cluster. The cluster has deployments with several database and frontend pods including a dedicated authentication server. Here is a diagram of such a setup:
Now a new customer signs up and you need to allocate infrastructure for the new customer. You want to isolate the two customers so that they have totally separate database and backend pods and don’t share any K8s resources. However, to save costs, you want to use spare capacity and run the infrastructure for both customers on the same K8s node.
The solution here is simple: simply move the first customer out of the default namespace and into a customer1 namespace. Duplicate that namespace for customer2 and voila! You now are using namespaces for multi-tenancy. This is how it will look like:
This is a great solution from a practical perspective. You were able to add multi-tenancy support to your application by simply duplicating the K8s resources. You didn’t need to modify the database and add a customerID column or change the code on your backend servers to understand that there can be more than one customer. Each customer lives in their own namespace on pods that know nothing about other customers.
From a security perspective, things aren’t so rosy. By default, different namespaces can communicate with one another. If customers themselves have privileged access to one namespace they could potentially access data from another namespace and therefore another customer. This is easy to fix with K8s network policies but they require a compatible CNI. You can also fix this independent of your CNI with Alcide’s embedded policies which allow either totally restricting traffic between namespaces or only allowing traffic to specific services in another namespace.
Namespaces for Team Segmentation
Another popular way of utilizing K8s namespaces is to assign different development teams / departments their own namespace. This lets each team manage their own application without interfering with the work of other teams. This can be a very powerful way to empower teams and give them independence. Here is a diagram of what that would look like for the company in our previous example:
Note that we assume here too that the company has taken on more clients and therefore had to scale up their deployments to multiple pods. However, in this method, all the pods can handle all the clients and multi-tenancy is implemented logically in the application and not by separation and duplication in the infrastructure.
From a security perspective, it is critical to realize that namespaces by themselves are absolutely not security boundaries. For example, if you have permissions to deploy pods within a certain namespace (but no other namespace) then there are a number of easy ways to deploy special pods that will grant root access to the entire cluster. (Some tricks are obvious and some are not. For example, you can escalate privileges merely by deploying a pod with a hostPath mount and then reading/writing data from the node’s filesystem.)
How do you solve these security problems without reducing developer independence? Must security come at the expense of convenience? One easy solution to these problems is to let security teams define cluster-wide security standards and then stand back and let development teams do their work independently. At Alcide, we prove a platform for cluster configuration-scanning, admission control, and security policies that let development teams and security teams both do their work without compromising on standards or independence. Furthermore, we support integrating configuration and security checks early in the CI pipeline so that developers encounter zero policy surprises when deploying code into production.
Namespaces for Security Segmentation
At last, we reach my favorite way of using namespaces. Namespaces in K8s can be used like old-school DMZs. You can use namespaces to group K8s resources by their security risk, the amount of confidential information they store, and their access to the external world. For example, web servers that receive client traffic can live in one namespace with security policies that allow communication with the external world but are otherwise extremely hardened. Databases that store confidential information can live in a hardened namespace that allows traffic to a very restricted set of users and resources. Devop tools and monitoring tools can live in their own respective namespaces which allow lots of internal traffic but no external traffic. Here is what this method would look like for our continuing imaginary SaaS company:
Note that the client-facing webservers have to communicate with both the backend databases and the secure authentication server. However, by segmenting our network into namespaces we can control and monitor that traffic to make sure it stays within specified limits.
One important reminder: namespaces are not security boundaries! This cannot be emphasized enough times. If an attacker has sufficient permissions in one namespace – and that namespace only – they can still gain root control of the cluster and move into other namespaces. (See explanation above when discussing the use of namespaces for different development teams.)
Network Segmentation Using Alcide
In summary, namespaces are a core Kubernetes feature for segmenting your cluster across different types of boundaries, whether they are multi-tenant boundaries, team boundaries, or security boundaries. However, by default, Kubernetes doesn’t prevent different namespaces from communicating with one another. To implement segmentation on the network level, you need a compatible CNI and even then there are a number of restrictions.
Another solution for network segmentation is to use Alcide’s microservices firewall which supports a wide variety of methods for segregating traffic across namespaces. You can choose how you want to use namespaces and Alcide will provide the means to enforce policies for how those namespaces communicate with one another. If you already have a multi-namespace cluster but don’t yet isolate namespace networks, then you can run the Alcide microservices firewall in monitor mode where violations are logged but not enforced. If you want to use namespaces for network segmentation, Alcide has you covered.