All Syself Autopilot clusters use Cilium as their networking layer.
In addition to providing networking and load balancing capabilities, Cilium includes powerful security features that allow operators to control how workloads communicate inside the cluster.
Using network policies, you can implement workload isolation, reduce lateral movement, and build a Zero Trust networking model for your applications.
For a broader overview of security architecture, see Zero Trust in Kubernetes.
Traditional Kubernetes security models often assume workloads inside a cluster can freely communicate with one another. While this simplifies application deployment, it can increase the impact of security incidents.
Cilium extends Kubernetes networking and security using eBPF, allowing policies to be enforced efficiently within the Linux kernel while providing advanced observability and security capabilities.
Key benefits include:
For more information about Cilium's security model, refer to the official Cilium documentation
Cilium supports both standard Kubernetes NetworkPolicy resources and its own CiliumNetworkPolicy resources.
For basic ingress and egress restrictions, standard Kubernetes Network Policies are often sufficient.
For more advanced use cases, CiliumNetworkPolicy provides additional capabilities including:
If you are building a security-focused Kubernetes platform, CiliumNetworkPolicy is generally the recommended approach.
For details, see this page in the Cilium documentation.
One of the key concepts in Cilium is workload identity.
Rather than relying solely on IP addresses, Cilium can identify workloads based on Kubernetes labels and enforce policies based on those identities.
This approach is particularly well suited for Kubernetes environments where pods are frequently created, destroyed, and rescheduled.
For example, instead of allowing traffic from a specific IP range, you can allow traffic from workloads labeled:
This makes policies more resilient to infrastructure changes and aligns with Zero Trust principles.
The following example allows only workloads labeled app=frontend to communicate with workloads labeled app=api :
Any other workload attempting to communicate with the API will be denied.
A common Zero Trust pattern is to start with a default-deny policy and then explicitly allow required communication paths.
The following policy denies all ingress traffic for selected workloads:
After applying a deny policy, additional policies can be created to allow only the traffic required by the application.
Many organizations want to control not only incoming traffic, but also which external services workloads can access.
Cilium supports DNS-aware and FQDN-based policies that allow administrators to define outbound communication rules using domain names rather than IP addresses.
Common use cases include:
For advanced examples, see:
https://docs.cilium.io/en/stable/security/dns/
Network policies are one of the most effective ways to implement Zero Trust principles in Kubernetes.
A common adoption path is:
Network policies are most effective when combined with:
For a broader overview, see Zero Trust in Kubernetes.
Before applying restrictive policies, it is important to understand how workloads communicate.
Hubble is Cilium's observability platform and provides visibility into network traffic flowing through the cluster.
It can help answer questions such as:
This visibility is extremely valuable when designing and troubleshooting network policies.
See Network Observability with Hubble.
When implementing network policies, we recommend:
A common mistake is attempting to isolate every workload immediately without first understanding application communication patterns.
Observability tools such as Hubble can significantly reduce the risk of accidental service disruptions.
Designing effective network policies requires understanding application communication patterns, security requirements, and operational tradeoffs.
The Syself team can help with:
If you would like assistance designing a secure Kubernetes networking architecture, contact the Syself team.