1 Oct 2026 · Conf42 DevSecOps 2026
Session: Conf42 session page
Video: YouTube
Slides: PDF, 23 slides
Abstract
Namespaces and NetworkPolicies are usually where multi-tenant Kubernetes isolation stops. That’s good enough to stop accidents. It isn’t good enough to stop a determined neighbor.
This talk walks through the cell-based architecture we built into OpenChoreo, an open-source internal developer platform and a CNCF Sandbox project. Every tenant’s environment gets its own cell: a namespace bound to a Cilium (eBPF) network policy boundary and its own observability scope, with traffic entering and leaving only through explicitly directional gateways.
We’ll break down the four traffic directions:
- Northbound — public ingress.
- Westbound — org-internal ingress.
- Southbound — egress to external services.
- Eastbound — org-internal egress.
Each direction is enforced with Cilium and an Envoy-based Kubernetes Gateway API implementation. You’ll leave with a concrete pattern for reasoning about tenant blast radius on Kubernetes: what a cell boundary actually stops, what it doesn’t, where RBAC/ABAC needs to pick up where network isolation ends, and the tradeoffs we hit running this in production across single-cluster and multi-cluster topologies.
Key takeaways
- A practical model (cells + directional gateways) for reasoning about tenant blast radius on Kubernetes, beyond “namespace + NetworkPolicy”.
- How to enforce egress-side controls (credential injection, circuit breaking, quotas) as a first-class part of tenant isolation, not an afterthought.
- Where network-layer isolation stops and RBAC/ABAC needs to take over.
- Real tradeoffs from running this across single-cluster and multi-cluster deployment topologies.