Kubernetes Network Policy Generator With Pre-Apply Connectivity Tests to Stop Lateral Movement
Build a tool that watches which services in a Kubernetes cluster actually talk to each other, generates least-connection network policies from that traffic, and tests them in CI against the expected connectivity before they are applied, so nothing legitimate breaks. Most clusters run with no network policies at all, which lets an attacker who breaks into one pod reach every database and internal API. This makes locking them down safe enough to actually do.
Intermediate
A small team, or one strong student willing to learn something new.1 to 2 semesters · 2 students
7 to ship
4 optional extrasSuggested stack
What you should ship
- A flow collector that records pod-to-pod and pod-to-external connections from Hubble or a small eBPF agent
- A connectivity map per namespace, labelled by workload rather than by short-lived pod IPs
- A generator that writes least-connection NetworkPolicy objects from observed flows, grouped by labels
- A connectivity test suite that checks every expected flow still works and selected forbidden flows are blocked
- A CI check that runs the tests in a kind cluster before policies reach the real cluster
- A risk report of the current cluster: which workloads can reach databases or the cloud metadata service
- An evaluation on at least three open source microservice demos with injected lateral movement attempts
If you have time left
- Audit mode rollout that logs would-be drops for a week before enforcing
- Detecting drift when new flows appear that the policies would block
- Egress policies for external domains where the network plugin supports them
- A visual diff of the connectivity map between two versions of the policies
The problem: one compromised pod can reach everything
By default, every pod in a Kubernetes cluster can connect to every other pod. A vulnerable image-resizing service, an exposed admin panel or a dependency with a remote code execution bug gives an attacker a foothold, and from there they can connect straight to the database, the cache, internal admin APIs and often the cloud provider's metadata endpoint. Network policies exist to stop exactly this, by allowing only the connections each service needs.
Few teams write them. Working out every legitimate connection by hand is tedious, the policy language is easy to get wrong, and a mistake causes an outage: the checkout service suddenly cannot reach payments. So teams leave the cluster flat, especially smaller companies and software houses running clusters for clients.
What already exists and the gap
- Cilium's Hubble shows observed network flows between workloads, and the Cilium network policy editor helps people write policies visually.
- Commercial editions of Calico offer policy recommendations based on traffic.
- Security scanners such as Kubescape report namespaces without network policies.
- Kubernetes NetworkPolicy itself is portable across network plugins that support it.
What is missing is an open, plugin-neutral workflow that closes the loop: observe real traffic, generate policies, prove with automated tests that legitimate traffic still flows and dangerous paths are closed, and only then apply. The testing step is the part that makes teams willing to switch policies on.
Inspiration
"Inside Job: Defending Kubernetes Clusters Against Network Misconfigurations" by Jacopo Bufalino, Jose Luis Martin-Navarro, Mario Di Francesco and Tuomas Aura (arXiv 2506.21134, 2025) analysed 287 open source applications from six organisations and found 634 network misconfigurations enabling lateral movement, far more than existing tools identified. Fixes they proposed were adopted for more than thirty applications. This project turns that kind of analysis into a tool a team can run on its own cluster.
What you build
- Platform engineers run the collector for a few days, review the connectivity map and generate policies per namespace.
- The CI check spins up the application in a kind cluster with the new policies, runs the connectivity tests and fails the change if a needed flow is blocked.
- Security reviewers get a before and after report: which workloads could reach the database before, and which can now.
The technically interesting part
- From flows to identities. Pods come and go with new IP addresses. Map each flow to stable workload identities using labels, deployments and service accounts, and choose label selectors that are neither too broad nor tied to a single pod.
- Least connection, not least effort. Generate the smallest set of rules that allows observed traffic, merging where safe so the policies stay readable. Keep DNS working, which is the most common thing people break.
- Rare but legitimate traffic. A nightly backup job or a monthly report may not appear in a few days of observation. Show low-confidence gaps, let people add expected flows by hand, and recommend audit mode first.
- Testing connectivity. Generate a test matrix from the map: for each expected flow, a probe that must succeed; for each sensitive target, probes from unrelated workloads that must fail. Run them inside the kind cluster.
- The metadata endpoint. Blocking pod access to the cloud provider's instance metadata service closes a common credential theft path. Include it in the default forbidden set where it is not needed.
How to evaluate it
- Breakage: apply generated policies to microservice demos (such as the Google Online Boutique sample) under synthetic load and count failed legitimate requests.
- Lateral movement: from a deliberately compromised pod, attempt to reach databases, other services and the metadata endpoint before and after. Report the reachable set.
- Coverage over time: how many days of observation are needed before generated policies stop missing flows, per application.
- Readability: number of rules generated against hand-written policies for the same application.
Suggested plan
- Weeks 1 to 3: kind with Cilium; deploy a microservice demo; read Hubble flows.
- Weeks 4 to 7: flow collector, workload mapping and the connectivity map.
- Weeks 8 to 11: policy generator and the connectivity test matrix.
- Weeks 12 to 15: CI check, evaluation and report.
- Optional second semester: audit mode rollout, drift detection and egress policies.
Who it is for, concretely
A team of five running a dozen services on a managed Kubernetes cluster, or a software house running clusters for several clients, that knows network policies are good practice but has never risked turning them on.
Path to a product
Cluster hardening is a standing item in customer security reviews and compliance checks, and this is a concrete, demonstrable fix. An open source tool with a hosted view of connectivity maps across clusters, or consulting around it, are realistic directions.
Scope warning
Work in local kind clusters and demo applications, not shared or production clusters. Support standard Kubernetes NetworkPolicy first; plugin-specific policy types are stretch goals. Never auto-apply policies to a real cluster without review.
Learn what you need on Sefism
- Platform engineering and SRE roadmap: running Kubernetes clusters well.
- Kubernetes Documentation: NetworkPolicy, services and DNS.
- kind (Kubernetes IN Docker): disposable clusters for the CI check.
- Network engineering roadmap: the networking basics behind policies.
- Cybersecurity roadmap: lateral movement and defence in depth.
- What is platform engineering, and how is it different from DevOps?: where this work sits.
Get help with this idea
The hard part is policies that are tight without breaking rare but real traffic. Tauseef can help you design the observation period, the test matrix and an evaluation that shows both safety and security. If you are new here, create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.