Kubernetes Network Namespace
Kubernetes has emerged as the de facto standard for containerization and orchestration for managing containerized applications. Among its many features, Kubernetes offers network namespace functionality, which plays a critical role in isolating and securing network resources within a cluster. In this blog post, we will delve deeper into Kubernetes Network Namespace, exploring its purpose, benefits, and how it enhances Kubernetes’s overall network management capabilities.
In simple terms, a network namespace is an isolated network stack that allows for the creation of separate network environments within a single Linux kernel. Kubernetes leverages network namespaces to provide logical network isolation between pods, ensuring each pod operates in its virtual network environment.
Highlights: Kubernetes Network Namespace
- The Role of Docker
In addition to my theoretical post on container networking – Docker & Kubernetes, the following hands-on series examines Linux Namespaces and Docker Networking. The advent of Docker makes it easy to isolate the Linux processes so they don’t interfere with one another. As a result, users can run various applications and dependencies on a single Linux machine, all sharing the same Linux kernel. This abstraction is made possible by using Linux Namespaces, which form the docker container security basis.
Before you proceed, you may find the following helpful post for pre-information.
Kubernetes Network Namespace. Introduction to both Docker networking and Linux. Discussion on the namespace and virtual interface types. Kubernetes network namespace and docker networking. Security options with Linux firewall and Netfilter.
Back to basics with Kubernetes Networking
Kubernetes users generally do not create pods directly. Instead, users create a high-level workload, such as a deployment, which organizes pods according to some intended spec. In the case of deployment, users specify a template for pods, along with how many pods (often called replicas) they want to exist.
Several additional ways to manage workloads, such as ReplicaSets and StatefulSets. Remember that Pods themselves are ephemeral, suggesting they are deleted and replaced with new versions of themselves.
Benefits of Kubernetes Network Namespace:
1. Enhanced Network Isolation: Kubernetes Network Namespace provides a robust framework for isolating network resources, ensuring that pods do not interfere with each other’s network traffic. This isolation helps prevent unauthorized access, reduces the attack surface, and enhances overall security within a Kubernetes cluster.
2. Efficient Resource Utilization: By utilizing network namespaces, Kubernetes optimizes the utilization of network resources. Pods within a namespace can share the same IP address range while maintaining complete isolation, resulting in more efficient use of IP addresses and reduced network overhead.
3. Simplified Networking Configuration: Kubernetes Network Namespace simplifies the configuration of network policies and routing rules. Administrators can define network policies at the namespace level, allowing for granular control over inbound and outbound traffic between pods and external resources.
4. Scalability and Flexibility: With Kubernetes Network Namespace, organizations can scale their applications without worrying about network conflicts. By encapsulating each pod within its network namespace, Kubernetes ensures that the network resources can scale seamlessly, enabling the deployment of complex microservices architectures.
How Kubernetes Network Namespace Works:
Kubernetes Network Namespace leverages the underlying Linux kernel’s network namespace feature to create separate network environments for each pod. When a pod is created, Kubernetes assigns a unique network namespace, isolating the pod’s network stack from other pods in the cluster.
Each pod has its network interfaces, IP addresses, routing tables, and firewall rules within a network namespace. This isolation allows each pod to operate as if it were running on its virtual network, even though it shares the same underlying physical network infrastructure.
Administrators can define network policies at the namespace level, controlling traffic flow between pods within the same namespace and across different namespaces. These policies enable fine-grained control over network traffic, enhancing security and allowing for the implementation of complex networking scenarios.
Docker Default Networking 101 & Linux Namespaces
Six namespaces are implemented in the Linux kernel enabling the core of container based virtualization. The following diagram displays per process isolation – IPC, MNT, NET, PID, USER, and UTS. The number on the right in the square brackets is each namespace’s unique proc inode number.
To implement namespaces in the Linux kernel, a structure called nsproxy was added. As the name suggests, it’s a namespace proxy. We have several userspace packages to support namespace – util-linux, iproute2, ethtool and wireless iw. In this hands-on series, we will focus on iproute2 userspace allowing management of the network namespace (NET) with the IP NETNS, and IP LINK commands.
Docker networking, essentially a namespacing tool, can isolate processes into small containers. Containers differ from VMs that emulate a hardware layer on the operating system. Instead, they use operating system features like namespaces to provide similar isolation without emulating the hardware layer.
Each namespace has an individual and isolated view allowing the sharing of the same host but with individual routing tables and interfaces.
Users may create namespaces, assign ports, and connect for external connectivity. A virtual interface type known as virtual Ethernet (veth) interface is assigned to namespaces. They act as pairs and have a similar analogy of an isolated tube – what comes in one end must go back out the other.
The pairing enables namespace connectivity. Users may also connect namespaces using Open vSwitch. The following screenshot displays the creation of a namespace called NAMESPACE, a veth pair, and adding a veth interface to the newly created namespace. As discussed, the IP NET and IP LINK commands enable interaction with the network namespace.
The following screenshot displays IP-specific parameters for the previously created namespace. The routing table will only show specific namespace parameters, not information from other namespaces. For example, the following ip route list command does not display the 192.168.1.1/24 interface assigned to the NAMESPACE-A.
This is because the ip route list command looks into the global namespace, not the routing table assigned to the new namespace. Instead, the command will show different route table entries, including different default gateways for each namespace.
Kubernetes Network Namespace & Docker Networking
Installing Docker creates three networks that can be viewed by issuing the docker network ls command: bridge, host, and null. Running containers with a specific –net flag highlights the network in which you want to run the container. The “none” flag puts the container in no network, so it’s completely isolated. The “host” flag puts the container in the host’s network.
Leaving the defaults places the container into the bridge default network. The default docker bridge is what you will probably use most of the time. Any containers connected to the default bridge, like a flat VLAN, can communicate freely. The following displays the networks created and any containers attached. Currently, no containers are attached.
The image below displays the initiation of the default Ubuntu image pulled from the Docker public registry. There are plenty of images up there that are free to pull down. As you can see, Docker automatically creates a subnet and a gateway. The docker run command starts the container in the default network.
With this setup, it will stop running if you don’t use crtl+p + ctrl +q to exit the container. Running containers are viewed with the docker ps command, and users can connect to a container with the Docker attach command. \
IPTables
Communication between containers can be restricted with IPTables. The Linux kernel uses different IPtables according to the protocol in use:
- IPtables for IPv4 – net/ipv4/netfliter/ip_tables.c
- IP6table for IPv6 -net/ipv6/netfliter/ip6_tables.c
- arptables for ARP -net/ipv4/netfliter/arp_tables.c
- ebtables for Ethernet – net/bridge/netfilter/ebtables.c
Docker Security Options
They are essentially a Linux firewall before the Netfilter, providing a management layer for adding and deleting Netfilter rules and displaying statistics. The Netfilter performs various operations on packets traversing the network stack. Check the FORWARD chain; it has a default policy of ACCEPT or DROP.
All packets reach this hook point after a lookup in the routing system. The following screenshot shows the permit for all sources of the container. If you want to narrow this down, restrict only source IP 8.8.8.8 access to the containers with the following command – iptables -I DOCKER -i ext_if! -s 8.8.8.8 -j DROP
In addition, to the default networks created during Docker installation, users may create user-defined networks. User-defined networks come in two forms – Bridge and Overlay networks. Bridge networks support single-host connectivity, and containers connected to an overlay network may reside on multiple hosts.
The user-defined bridge network is similar to the docker0 bridge. An overlay network allows containers to span multiple hosts, enabling a multi-host connectivity model. However, it has some prerequisites, such as a valid data store.
Conclusion:
Kubernetes Network Namespace is a powerful feature that provides enhanced network isolation, efficient resource utilization, simplified networking configuration, and scalability within a Kubernetes cluster. By leveraging network namespaces, organizations can build robust and secure containerized applications, ensuring the smooth operation of their microservices architecture.
As Kubernetes continues to gain popularity, understanding and harnessing the capabilities of Network Namespace becomes increasingly important. By incorporating this feature into your Kubernetes deployments, you can unlock the full potential of containerized applications while maintaining a secure and scalable network environment.
- DMVPN - May 20, 2023
- Computer Networking - April 7, 2023
- eBOOK – SASE Capabilities - April 6, 2023