Egress control built to survive container escape
Enforce outbound traffic outside the compromised node
— where attackers can't disable it.
Neuwerk is a lightweight egress gateway that enforces deny-by-default network policies outside the trust boundary of your workload, where a dedicated DPDK dataplane keeps enforcement fast and isolated from compromised nodes.
Start with a single VM demo, then move the same policy model into audit mode before enforcing it.
How It Works
External enforcement that scales
Deployment Architecture
The gateway runs on a separate security boundary from your workloads — compromising a workload node does not compromise enforcement.
Key Properties
- Node compromise doesn't affect enforcement
- DPDK provides a dedicated high-throughput packet dataplane
- Can replace NAT gateway or cloud firewall egress paths
- Audit mode lets you tune policy before enforcing it
Integration
- Runs adjacent to Kubernetes as dedicated network infrastructure
- Compatible CNI configurations preserve source IP visibility at the gateway
- Overlay designs that hide pod source IPs are not currently supported
Deployment model: treat the gateway as dedicated network infrastructure outside the workload node. For Kubernetes, compatibility depends on pod source IPs staying visible to the gateway.
Why Existing Solutions Fall Short
If you've tried to lock down egress, you've probably hit these walls.
CNI Policies & Service Mesh
(Cilium, Calico, Istio)
Great for microsegmentation — but they run on the workload node. Once compromised, an attacker can disable or bypass them.
DNS-Only Filtering
(Route53 Resolver, CoreDNS policies)
Blocks DNS lookups but not direct IP connections. Trivial to bypass with hardcoded IPs or alternative DNS.
Cloud Network Firewalls
(AWS Network Firewall, Azure Firewall)
External enforcement that works — but expensive, complex to configure, and not portable across cloud vendors or on-prem.
Traditional NGFWs
(Palo Alto, Fortinet, Zscaler)
Built for broad perimeter security, not focused cloud egress. They can do DNS, SNI, and optional TLS inspection — but licensing and throughput-based pricing get expensive fast.
Why isn't node-local enforcement enough?
Tools like Cilium, Calico, and sidecar-based controls run on the workload node — useful when the node is trusted.
But if an attacker gets root, they can tamper with local policy components or route around them. The node is compromised, so controls running there are part of the blast radius.
Neuwerk uses a DPDK-based gateway on a separate security boundary — outside the workload's trust boundary.
Compromising a workload node does not give access to the gateway. That separation is what makes default-deny egress realistic even under node compromise.
Result: most "secure" environments quietly run with wide-open egress .
Open Source
The dataplane, control plane, UI, and cluster features ship in the Apache 2.0 codebase. Build it, audit it, and run it without feature gates.
Open Source
Apache 2.0 License
Support & Design Partners
Help with rollout, migration, and feedback loops
- Design partner access for early rollouts
- Commercial support for deployment and migration work
- Operator reviews for audit-mode rollout plans
- Direct feedback loop on roadmap gaps
No feature gating: SSO, clustering, and the policy engine are part of the OSS release. Support is about helping operators ship it safely, not hiding product capabilities.
We believe security tools should be inspectable. You can audit every line that touches your packets.
How This Compares
Where Neuwerk fits in the egress control landscape.
Cilium Network Policies
Service Mesh (Istio)
DNS Filtering (Route53)
AWS Network Firewall
Survives compromiseTraditional NGFW
Survives compromiseNeuwerk
Survives compromiseLighter than NGFWs
No IDS/IPS, threat intelligence, user tracking — just egress enforcement.
Harder than DNS filtering
Enforces at packet level, not just DNS resolution.
External to workloads
Unlike CNI/service mesh, survives node compromise.
Optional TLS interception
Supports HTTP-aware TLS interception when deeper inspection is worth the trade-off.
Policy as Code
Define hostname rules and optional TLS metadata constraints in Git, deploy them through the API, and roll them out in audit mode first.
Infrastructure-native workflow
Version-controlled
Policies live in Git. Review changes in PRs. Roll back with confidence.
CI/CD native
Apply policies in your pipeline. No manual console clicks.
Terraform, Pulumi, or raw API
Use your existing IaC stack. We expose a simple RESTful API.
Audit-first rollout
Start in audit mode, observe traffic, and only then switch to enforce.
API-first design
- RESTful API with OpenAPI spec
- Idempotent policy updates
- Audit and enforce policy modes
- Service-account auth for automation
Hostname + TLS Metadata Example
{
"mode": "audit",
"name": "github-egress",
"policy": {
"default_policy": "deny",
"source_groups": [
{
"id": "prod-cluster",
"sources": {
"cidrs": ["10.20.0.0/22"]
},
"default_action": "deny",
"rules": [
{
"id": "allow-github-dns",
"action": "allow",
"match": {
"dns_hostname": "^(?:api\\.github\\.com|github\\.com)$"
}
},
{
"id": "allow-github-https",
"action": "allow",
"match": {
"proto": "tcp",
"dst_ports": [443],
"tls": {
"mode": "metadata",
"sni": {
"exact": ["api.github.com"]
}
}
}
}
]
}
]
}
}Why Policy as Code matters
Audit trail built-in
Every policy change is a Git commit. Who changed what, when, and why is answered by your existing tooling.
No console access needed
Engineers submit PRs. Security reviews and approves. No one needs admin access to a web UI.
Observe before enforce
Audit mode lets the policy evaluate live traffic before it starts blocking production flows.
Who This Is For
Platform Engineers
Building internal developer platforms who need egress controls that don't break every deploy
Security Teams
Who need demonstrable egress controls without slowing platform teams down
Regulated Industries
Fintech, healthcare, and others who need audit-ready egress enforcement
Cloud-Native Teams
Replacing Squid proxies, egress gateways, or home-grown solutions
Deployment Boundaries
- Neuwerk runs adjacent to Kubernetes as dedicated network infrastructure, not as an in-cluster add-on.
- Compatible CNI configurations keep source IPs resolvable back to pod IPs at the gateway.
- Overlay networks that hide or rewrite pod source IPs before the gateway are not currently supported.
Ready to Lock Down Egress?
Start in audit mode, learn what your workloads are actually doing, then turn on enforcement when the policy is ready.
Open Source
Start with the single-VM demo, then carry the same policy model into the appliance image for real rollout work.
Design Partner Program
Get rollout help, migration guidance from NAT or cloud firewall paths, and direct feedback loops on missing pieces.
Questions? Check the documentation, browse the source, or email hello@neuwerk.io