Cilium Authentication

Published
Length
3 min read

Luis Felipe Dias

All posts

You set up cilium authentication by adding an auth rule to your network policy. This rule tells the node agent to check both workload identities before packets flow. Teams often build these rules to lock down service traffic inside Kubernetes clusters. Broad namespace labels can let extra pods pass the check and talk to databases. When labels match too many apps, any pod in that group gains trust. How cilium authentication works in a cluster Standard network policies only look at IP addresses

Multi-Factor Authentication (MFA) + Cilium Network Policies: the complete guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free white paper. No spam. Unsubscribe anytime.

You set up cilium authentication by adding an auth rule to your network policy. This rule tells the node agent to check both workload identities before packets flow. Teams often build these rules to lock down service traffic inside Kubernetes clusters. Broad namespace labels can let extra pods pass the check and talk to databases. When labels match too many apps, any pod in that group gains trust.

How cilium authentication works in a cluster

Standard network policies only look at IP addresses and ports in the kernel. IP addresses change fast in Kubernetes as pods start and stop on nodes. Cilium ties a numeric security identity to each pod based on its labels. When a policy asks for an identity check, the kernel pauses the first packet. The data path then asks the local user space agent to verify both ends.

The source agent and the destination agent run a mutual TLS handshake. They use short-lived certificates from a cluster trust store like SPIRE to prove identity. The handshake runs out of band between the two node agents. App pods do not need sidecar containers or code changes to run this check. Once the agents confirm the certificates, they save the result in a kernel map.

The kernel then lets packets flow between those two identities until the certificate expires. You can combine this identity check with WireGuard encryption at the node level. WireGuard encrypts the packets in transit across the network wire. The mutual handshake proves that the remote pod holds a valid cryptographic identity. Together, they stop spoofed packets and block untrusted workloads from opening a socket.

Manage certificates and identity rules at scale

Running mutual checks across a large cluster requires a solid certificate authority setup. The control plane watches pods start and assigns SPIFFE identities to each workload. A local agent on each node fetches the right certificate for every local pod. It rotates these keys before they expire so active traffic does not drop. Platform teams must watch the trust server closely to avoid cluster outages.

If the identity server goes down, cached sessions continue to pass traffic for a while. New pods or expired sessions will fail the handshake and drop packets right away. Teams should scope auth policies to sensitive paths first, like payment or user stores. Applying checks to every single pod at once adds work to the node agents. Start with high-risk backend services and check your agent logs for handshake drops.

Multi-Factor Authentication (MFA) + Cilium Network Policies: architecture patterns and best practices

Continue reading? Get the full guide.

Free. No spam. Unsubscribe anytime.

What network identity solves and what it misses

Network identity checks solve a major problem for platform teams in shared clusters. They prove that a workload is who it claims to be before traffic flows. A pod with a spoofed IP address enforces policy on the mutual certificate check. This keeps rogue pods in other namespaces from talking to protected internal APIs. It also satisfies strict audit rules that demand cryptographic proof between cluster services.

Still, network rules only check which pod opens the socket to another pod. They do not inspect the database queries or shell commands sent by an engineer. Once an admin pod or app passes the check, the network trusts every packet. A valid workload or user session can still run a drop table statement. It can also pull raw customer emails, phone numbers, or card numbers in bulk.

Network policies also do not link cluster actions back to a human user identity. When an engineer runs a debug pod, the network only sees the pod label. Audit logs show that a trusted pod talked to the database port. They do not show which person ran the query or what records came back. Protecting data requires control over individual commands and queries, not just pod sockets.

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 authentication encrypt pod traffic by itself?

No, the auth handshake only checks workload identities out of band between node agents. To encrypt the actual data packets, you must also turn on WireGuard or IPsec.

Do I need sidecar containers for mutual checks in Cilium?

No, Cilium runs the handshake through a node agent on each Kubernetes host. Your app pods run without sidecar containers, which saves memory and CPU across the cluster.

What happens when a workload certificate expires during an active session?

The node agent rotates certificates in the background and runs a new handshake by default. If the trust store is down and renewal fails, the kernel blocks new packets.

Save the open-source gateway.

hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.