Cilium Flow Logs
You collect cilium flow logs by turning on the Hubble network layer in Kubernetes. This tool reads packet events from the Linux kernel and saves them as records. Teams use these records to see which pods talk to each other. They also check these logs to find dropped packets and fix broken network rules. Still, teams often grant broad cluster roles so devs can read these flow events. When roles are too broad, users can see sensitive network paths across all namespaces. They might also gain right
Cilium Network Policies + Kubernetes Audit Logs: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You collect cilium flow logs by turning on the Hubble network layer in Kubernetes. This tool reads packet events from the Linux kernel and saves them as records.
Teams use these records to see which pods talk to each other. They also check these logs to find dropped packets and fix broken network rules. Still, teams often grant broad cluster roles so devs can read these flow events. When roles are too broad, users can see sensitive network paths across all namespaces. They might also gain rights to change cluster rules or read private app data.
How cilium flow logs work in your cluster
Cilium uses small programs inside the Linux kernel to watch network traffic. Every time a pod sends or gets a packet, the kernel notes the event. It captures the source pod, the target pod, the port, and the verdict. The verdict shows if the network rule allowed or dropped the packet.
A local agent on each node collects these events into a ring buffer. You can set up the agent to write these records to a local file. From there, a log shipper reads the file and sends it to storage. Teams filter the output so they only store drops or specific app traffic. This setup keeps storage costs low while saving the most useful network events.
Setting up log filters and role limits
Full packet logs on a busy cluster create huge amounts of data fast. If you log every allowed packet, your disks can fill up in hours. Good setups use filters to record only denied connections or traffic to key databases. You can also group similar flows together over short time windows to save space.
Access to the log collector also needs tight role limits in Kubernetes. You should bind read roles to specific namespaces rather than the whole cluster. This step ensures an app team only reads network flows for their own pods. It stops them from mapping out other services running on the same nodes.
Cilium Network Policies + Kubernetes Audit Logs: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network logs solve and where they fall short
Network flow records are great for checking if your firewall rules work well. They show you when a pod tries to reach an unknown external address. They also help you spot broken service links when an app fails to load. You get a clear map of how packets move between nodes and pods.
Still, network logs only show that a connection happened between two endpoints. They do not show who logged into a pod or ran a database query. Once a user or app passes the network check, the flow log stops helping. It cannot inspect the actual commands, SQL queries, or data payloads inside the connection. If an engineer opens a shell into a production pod, the flow looks normal. If a query pulls raw emails or card numbers, the packet log stays green. Network rules decide which pods can talk, not what users do inside the session.
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
Do cilium flow logs slow down cluster network speed?
Kernel event capture adds very little delay to normal pod traffic. Writing every single event to disk can use extra CPU and memory on busy nodes. Using filters to log only dropped packets keeps node load very low.
Can cilium flow logs see inside encrypted database traffic?
No, flow logs only read packet headers, ports, and pod identity tags. They cannot read the SQL statements or data inside an encrypted database session. You need query logging and data masking to protect fields like phone numbers.
How long does the node keep flow records in memory?
Each node stores recent events in a small memory ring buffer. On a busy node, new network events overwrite old ones in a few minutes. To keep records for days, you must export them to external log storage.