Cilium Devices
You set up cilium devices by telling the networking agent which Linux interfaces handle cluster traffic. By default, the agent scans the host and picks active network cards on its own. Many teams rely on this default behavior when they build new clusters. Still, broad permissions let engineers change these settings without oversight, which can drop pod traffic. How cilium devices work on Linux nodes Cilium uses Linux kernel programs to move packets between pods and external networks. To do th
Cilium Network Policies: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up cilium devices by telling the networking agent which Linux interfaces handle cluster traffic. By default, the agent scans the host and picks active network cards on its own. Many teams rely on this default behavior when they build new clusters. Still, broad permissions let engineers change these settings without oversight, which can drop pod traffic.
How cilium devices work on Linux nodes
Cilium uses Linux kernel programs to move packets between pods and external networks. To do this job, the agent must attach those programs to physical or virtual network cards. These selected interfaces are your cilium devices. When a node boots, the agent checks the host routing table to find valid network paths. It looks for interfaces that hold default routes or match cluster IP ranges. Once the agent finds these cards, it loads traffic filters onto them. If a server has one network card, this process works with zero manual steps. Multi-homed servers with storage networks, management ports, and public cards need stricter rules. On complex hosts, you define an explicit list of interfaces for the agent to use. You can also match cards by name patterns so the agent ignores private backup links. This step keeps pod packets on fast data links and off slow management networks.
Why manual interface changes create cluster risk
Picking the right network cards keeps cluster routing fast and predictable. It also makes sure nodePort services and load balancers listen on the right ports. Yet managing these settings across dozens of nodes creates a major security gap. To inspect or fix device bindings, engineers often ask for full cluster admin roles. They also log in to Linux nodes over SSH to check host link states. Native Kubernetes roles decide who can enter the cluster or edit the main agent map. Those roles do not check what an engineer does once a live shell starts. An admin checking a broken network card holds enough power to delete workloads. They can also read secret keys or query databases that store emails and card numbers. Native role bindings cannot separate safe read commands from dangerous state changes during live fixes. Teams need a way to let engineers check network state without giving away full node control.
Best practices for multi-interface nodes
Start by mapping every network card on your worker nodes before you deploy the agent. Give your primary data interfaces consistent names across all machines in the fleet. Tell the agent to bind only to those specific data cards during startup. Exclude virtual bridges, local loopback adapters, and storage interfaces from the agent scope. Test these rules in a staging cluster to confirm that external service traffic flows as expected. When engineers need to check interface status on live nodes, limit their command scope. Do not hand out shared root keys or long-lived cluster admin tokens for routine checks. Instead, review and log every command that touches node networking or cluster maps. Mask sensitive values like phone numbers or national IDs if logs capture app payload data.
Cilium Network Policies: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What happens if the agent picks the wrong network interface?
Pod traffic may route over slow links or fail to reach outside networks. NodePort services might also bind to private cards that external users cannot reach.
How do I check which interfaces the agent uses right now?
Run a status check inside the agent pod to view the active device list. The output shows every Linux interface that holds an attached packet filter.
Can I add a new network card without restarting the node?
Yes, the agent watches the Linux kernel for link changes and detects new cards. You may need to restart the agent pod if you change static device rules.