Cilium Hostport
You enable cilium hostport by turning on eBPF host routing in your cluster network setup. This feature maps a port on the host node straight to a pod without iptables. Platform teams use this setup when pods need direct node traffic for ingress or logging. Still, opening host ports with broad network rules exposes node interfaces to unwanted traffic. If a team grants wide cluster roles, any user can bind pods to host ports. That creates port conflicts and opens a path past standard pod network c
Cilium Network Policies: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You enable cilium hostport by turning on eBPF host routing in your cluster network setup. This feature maps a port on the host node straight to a pod without iptables. Platform teams use this setup when pods need direct node traffic for ingress or logging. Still, opening host ports with broad network rules exposes node interfaces to unwanted traffic. If a team grants wide cluster roles, any user can bind pods to host ports. That creates port conflicts and opens a path past standard pod network controls.
How cilium hostport works under the hood
In older Kubernetes setups, a daemon watches the API and writes long iptables rule chains. As a cluster grows, the Linux kernel must read every rule in order for each packet. This adds delay and burns CPU time on every host node.
The cilium hostport design replaces those long rule lists with eBPF programs in the kernel. When you deploy a pod that asks for a host port, the agent updates a map. When traffic hits the node interface on that port, the eBPF program reads the map. It rewrites the packet header right away and sends the traffic straight to the pod. Return packets go back through the same path to restore the node source address. You do not need extra port map plugins when the eBPF replacement mode runs.
What native host port routing solves and what it misses
Using eBPF for host port mapping solves the speed problem of legacy firewall rule lists. Packets reach the pod faster, and nodes use less memory and CPU during high traffic. It also lets network policies filter traffic that enters through a host port on the node. Teams can block bad source addresses before packets ever reach the pod network.
Yet this network setup only controls how packets move from a node port to a pod. It does not check who sends a command or what happens inside an open session. Once an engineer or script connects to a service or pod, network rules stop helping. A user with cluster permissions can run any command or read raw database rows at will. Network logs show that a packet crossed a port, not which query or command ran. Teams still face the risk of exposed secrets, broad admin roles, and unlogged queries.
Cilium Network Policies: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to keep host port setups safe in production
Start by limiting which pods can claim a port on the underlying host node. Use pod security rules to block host port requests across all standard app namespaces. Only allow ingress routers or trusted system agents to bind to node ports. Keep a clear list of reserved port numbers so two pods do not clash on scheduling.
Next, pair your host port setup with strict ingress network rules on the node. Never leave a host port open to all internal networks without a source filter. Even with tight network rules, you still need visibility into what users do inside sessions. When engineers debug nodes or query services behind those ports, check every action at runtime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does cilium hostport need the standard CNI portmap plugin?
No, you do not need the separate portmap plugin when native host port support runs. The eBPF agent handles port mapping directly inside the Linux kernel without extra chained plugins.
Why do pods get stuck pending when using host ports?
A pod stays pending if every node already has another pod using that exact host port. Kubernetes can only place one pod per host port on a single node at one time.
Can network policies filter traffic directed to a host port?
Yes, eBPF host routing lets standard network policies inspect traffic entering through a host port. You can write ingress rules to allow or drop packets based on source address labels.