Kubernetes Network Isolation
In the 1980s there was a funny television commercial for an insurance company that was debauching many other insurance companies. These hideous competitors trained their agents to “Say NO, deny the Claim!” thereby denying customers the benefits of the insurance policy they had purchased. It always made me chuckle and I still remember the chant to this day. I want to show you how you can do this, “Say no, deny pod access!” in Kubernetes using NetworkPolicies applied to your application deployments.

Recently while working with a customer who is quite new to Docker and the world of Kubernetes, they were inquiring about how to isolate their applications from each other in a shared Kubernetes cluster.
In a previous blog post entitled Kubernetes Workload Isolation I discussed how customers have segmented their cluster by using a combination of VLAN’s, Collections, and Namespaces. But if you are not utilizing VLAN’s to segment your networking among VM’s and if you are not using Collections to separate VM’s into different RBAC groups then you will need a different approach.
NetworkPolicies to the Rescue
Kubernetes namespaces provide isolation for administration purposes but are not sufficient to prevent network traversal. Kubernetes NetworkPolicies, however, provide the guardrails needed to restrict East-West traffic between pods and services in the cluster as well as North-South traffic between the pod and external resources.
David Thompson posted how to use Kubernetes NetworkPolicies in Docker Enterprise Edition to isolate applications from each other. He provides a tutorial-based approach around complete application isolation, including intra-pod isolation, and moves towards a final solution that opens up traffic from your ingress controller. He talks about how to:
- deny all traffic to or from your pods
- allow traffic between pods inside a namespace
- allow ingress traffic from external sources to your pods
I want to take that technical insight and discuss how we can apply that information to your environment and discuss a practice around applying NetworkPolicies from a governance perspective.
Implementation Approach
It gets interesting when the development team is ready to deploy their application as Kubernetes pods. Security folks want the application as secure as possible including network access. Network folks want to ensure that networking follows enterprise standards and includes appropriate firewalls to isolate traffic. While developers just want their application to communicate properly amongst its various containers. I will now show you one approach to solving these lofty goals with NetworkPolicies.
Step 1 – Deny All
Like the television commercial chant “Say no, deny the claim!”, I would generally recommend starting with the most restrictive network permissions. New application teams should have a default NetworkPolicy that denies all ingress and egress traffic to all pods within their namespace.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: ns-app1
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
Using the previous NetworkPolicy specification you can achieve total isolation by invoking: kubectl apply -f deny-all-np.yaml
.
Let’s break this down. In the previous NetworkPolicy, you will notice that the podSelector
is an empty set which means it applies to all pods. Kubernetes NetworkPolicies take a white-list approach. The policyTypes
list both Ingress
and Egress
but does not specify any other attributes which means that it is white-listing nothing; effectively denying everything.
Applied During On-Boarding
This kind of NetworkPolicy would typically be applied to the namespace as it is created during the team’s on-boarding process. The on-boarding process is ideally a self-service portal where a team leader can invoke an automated process which will setup the team members inside of Docker Enterprise with appropriate permission to build, publish, and deploy their Kubernetes application. This should be controlled via automation or by an individual you trust to manually do the right thing. No apps are deployed at this time, but if someone subsequently does deploy an app then the default policy is to deny all traffic.
Step 2 – Allow Egress and Intra-Pod Access
In this second step, there are two parts. First, we remove the egress restriction because our applications will often need to access the outside world. So, in the following specification, you will see Egress has been removed from the list of policyTypes. This will grant your pods network access outside of the pod.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-internal-ingress
namespace: ns-app1
spec:
podSelector:
matchLabels:
project: project-app1
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
ns-id: ns-app1
podSelector:
matchLabels:
project: project-app1
The second part of Step 2 is to allow intra-pod network access. Without this access your pods will not be able to communicate with each other in order to collaborate and produce the desired result. To do this we need to include some selectors under a new label of ingress:
. We are essentially allowing ingress traffic from:
the namespace selector and the pod selector. This will allow the pods in ns-app1
namespace to communicate with other pods in the same namespace and these pods must have a label of project-app1
.
Keep in mind that NetworkPolicies are cumulative and inclusive. So this second NetworkPolicy will ride on top of the first and only open up what is required through the white-listing of ingress rules.
Applied by Pipeline During Deployment
Intra-pod network access could be enabled by the pipeline prior to deployment of the application. It could also have been done as part of the on-boarding process if you know what all your namespaces will be. Either way, it is not in the developers’ hands to establish network policies. Rather, it is a security/network concern and it is typically implemented as part of an automation process.
Step 3 – Allow Ingress
The type of application you are developing will determine if you need ingress traffic from a source external to the cluster. A typical web application has front-end websites that need ingress traffic and the supporting back-end micro-services do not. A mobile application may need ingress access to the API but that would often be handled by an application gateway in which case only the gateway needs ingress traffic.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-ingress-app1
namespace: ns-app1
spec:
podSelector:
matchLabels:
project: app1-web
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
ns-id: ingress-nginx
This NetworkPolicy is adding an inclusive white-list rule which allows traffic from the ingress-nginx
namespace. This NetworkPolicy is very specific about the matchLabels
of the podSelector
to target an individual set of pods that represent the web app that should handle ingress traffic.
Applied by Pipeline or Portal
The sample NetworkPolicy is very specific to this application. It is not generally applied to all applications.
The application of this NetworkPolicy should be handled by either the CI/CD pipeline or by a self-service portal. In both scenarios, the template is pre-defined and controlled outside of developer hands. The pipeline/portal will fill in the appropriate namespace and project name into the template while the developers have the flexibility to specify the ingress namespace.
Summary
In this three-step process to achieve application network isolation, I have prescribed that in no way are the developers responsible for or have any control over the NetworkPolicy. Rather, they can have these pre-defined and trusted templates applied to their project in an automated fashion. In the end, the application is isolated and yet has the proper source for ingress traffic.
This will require security, network, firewall, operations, CI/CD, and development teams to all be involved in some coordinated effort to standardize on a corporate strategy for application network isolation. That strategy must involve automation using both CI/CD and self-service portal to apply these NetworkPolicies.
As always, Capstone IT is here to help you with your Kubernetes needs.
Mark Miller
Solution Architect
Docker Accredited Consultant
