By Reuven Harrison
Why Network Segmentation?
A well segmented network can stop a malicious attack by preventing lateral movement while a loosely segmented network is prone to attacks as seen, for example, in the recent Capital One breach.
Network Segmentation in Kubernetes
Kubernetes network policies provide a good means of network segmentation in a Kubernetes cluster but they can be difficult to operate.
Writing a least-privilege policy by hand is a daunting task. A typical application in Kubernetes requires hundreds of connections: between services, from the outside (ingress) and to external end-points (egress) — quite impossible to craft by hand, especially when the application is continuously morphing with each pull request being merged and promoted.
On top of that, Kubernetes network policies have other technical challenges as explained in my post here.
As a result of these challenges, many Kubernetes applications are overly exposed, even critical, production apps.
Segmenting Kubernetes (and OpenShift) Automatically
The good news is that there is no need to write network policies manually because this process can be fully automated as follows:
1. Register to Orca
Signup to Orca, which is free and fully functional to evaluate, and follow the instructions to connect it to your cluster (requires cluster-admin permissions). This should take a couple of minutes at the most.
2. Build your policy
Log into Orca and view the service graph — this is a real-time view of the East-West and North-South connectivity in your cluster:
Click the “New Connections” button to see a list of connections made in the cluster:
Add to your policy only the connections you want to allow:
3. Generate your Kubernetes network policy
Export your policy to a Kubernetes Network Policies yaml file. Edit as needed and apply to your cluster using kubectl.
That’s it!
Advanced: Integrate Policy Generation into the CI/CD Pipeline
To make the process even better — more efficient and minimizing the risk of inadvertently adding malicious connections from your production environment to your policy — you can run your application in a clean, test environment in which all connections discovered are those you want to have in your policy.
CI/CD practices such as Blue-Green deployments and automated testing are ideal for this, as they enable you to test a fully operational environment and generate its policy before promoting it to production.
Summary
This post shows you how to enforce tight network segmentation for your Kubernetes micro-services with automatically generated Kubernetes network policies. Try it and let us know how it’s working for you.
