Advanced Network Policy

Maintain identity based policies effectively at scale

How can I implement granular security policies when IPs change quickly?

Kubernetes network policies provide an application-centric construct for defining security policies at L3/L4 level. One of the primary challenges is how to effectively enforce security policies when traditional IP rules don't apply. Modern systems often churn IPs dynamically making it difficult to rely entirely on TCP/UDP ports and IP addresses for scaling security policies.

Security illustration

Application and DNS Aware Policies with Cilium

Cilium implements Kubernetes Network Policies for L3/L4 level and extends with L7 policies for fine grained API-level security for common protocols such as HTTP, Kafka, gRPC, etc. For example, the endpoint with label role=frontend can only perform the REST API call GET /userdata/[0-9]+, all other API interactions with role=backend are restricted.

Scaling policies with Identities not IPs

Cilium decouples security from network addressing using workload identity derived from labels and metadata, allowing for more flexible and efficient scaling without constant security rule updates.

identities with cilium

Policy visualization and editing

Cilium provides a simple and intuitive network policy editor UI easing the cognitive overhead of writing network policies. It can often be painful to get the YAML syntax and formatting right when implementing network policies. There are many subtleties in the behavior of the network policy specification (e.g. default allow/deny, namespacing, wildcarding, rules combination, etc) that can result in misconfiguration.

Cilium network policy editor UI

Multi-cluster Policies

Cluster Mesh, Cilium's multi-cluster implementation features Network policy enforcement spanning multiple clusters. The same policy enforcement you are familiar with from a single cluster simply expands and works across multiple clusters.

cilium multi cluster illustration

Cluster-wide Policies

Cilium also features cluster wide policies which are non-namespaced and cluster scoped via the extended CiliumClusterwideNetworkPolicy CRD. Using cluster-wide policies, administrators can enforce consistent policies across all namespaces, simplifying network management.

Cilium network policy editor UI

Who’s using Cilium’s Advanced Network Policy?

  • Observability for a highly available multi cluster environment with Hubble

    Utmost achieved Zero Trust Networking by replacing their existing CNI with Cilium to address networking, security, and visibility for container workloads. Utmost processes 1207 flows per second, each validated against a multitude of network policies to approve or deny access.

  • How ClickHouse is Using Cilium to Implement Efficient Network Policies

    ClickHouse turned to Cilium as their preferred networking solution to take advantage of eBPF performance and simplify the process of isolating customers from each other. Cilium enabled them to create dedicated CiliumNetworkPolicies for each customer’s Kubernetes namespace to control access to specific resources, even if a customer manages to break into their Kubernetes pods.

  • Self-service, Zero Trust Network Security

    Rabobank turned to Cilium as their preferred network security solution. Cilium is the default Container Network Interface (CNI) for Rabobank’s API platform team, enabling them to configure network policies easily, allowing for automated allow listing of their API providers. The shift from IP allow listing to using FQDN has significantly eased the maintenance and troubleshooting of their platform.

  • Enforcing Network Policies for Host Processes via eBPF

    Cilium network policies can secure communication between the Kubernetes API server and the kubelet by assigning them identities and using a CiliumNetworkPolicy to ensure that only traffic from the API server is allowed to reach the kubelet. eBPF provides an efficient means to enforce network policies for host processes. Cilium utilizes eBPF programs that attach to network interfaces to identify the source of network traffic. These programs insert the identity of the sending process into the packet header, which the receiving host can use to determine whether to allow the traffic.

  • Migrating to Cilium for Better Networking, Visibility and Security

    "In the beginning, it was hard for our developers to write network policies because we were in our early Kubernetes adoption phase. Everyone had to learn a lot of stuff in Kubernetes and then also had to learn how to write network policies. Cilium helped reduce the mental overhead and helped speed up our development process so that we can bring new features to customers faster."

    Jan Jansen, Platform Engineer, G DATA

  • Implementing Zero Trust Security with Cilium

    "We migrated all our clusters to Cilium, enhancing our cell-based architecture with Cilium's advanced Layer 3 and Layer 4 network policies. Our setup also includes Hubble, integrated with Cilium Layer 3 network policies for observability within the cell."

    Lakmal Warusawithana, Senior Director - Cloud Architecture, WSO

Want to Learn More?

Join the Cilium Slack

Cilium is an open source project that anyone in the community can use, improve, and enjoy. We'd love you to join us on Slack! Find out what's happening and get involved.

Join the Slack

Read the Documentation

Cilium has extensive documentation that covers its features and use cases. The docs also features tutorials for common user stories.

Read the Docs

Get Help

Get help with Cilium through Slack, Github, training, support, and FAQs. The community can also help you tell or promote your story around Cilium.

Get Help