## Introduction

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](/docs/hetzner/apalla/security/zero-trust).

## Why Cilium?

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:

- High-performance policy enforcement
- Workload identity-based security
- Layer 3, Layer 4, and Layer 7 filtering
- DNS-aware policies
- Deep network visibility
- Integration with Hubble for observability

For more information about Cilium's security model, refer to the [official Cilium documentation](https://docs.cilium.io/en/stable/security/)

## Kubernetes NetworkPolicy vs CiliumNetworkPolicy

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:

- DNS-aware policies
- Layer 7 HTTP filtering
- Identity-based policies
- FQDN filtering
- Enhanced observability

If you are building a security-focused Kubernetes platform, CiliumNetworkPolicy is generally the recommended approach.

For details, see [this page](https://docs.cilium.io/en/stable/security/policy/) in the Cilium documentation.

## Understanding workload identity

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:

```yaml
app: frontend
```

This makes policies more resilient to infrastructure changes and aligns with Zero Trust principles.

## Example: Restrict access to an API

The following example allows only workloads labeled `app=frontend` to communicate with workloads labeled `app=api`:

```yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-policy
spec:
  endpointSelector:
    matchLabels:
      app: api

  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
```

Any other workload attempting to communicate with the API will be denied.

## Example: Default deny policy

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:

```yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: default-deny
spec:
  endpointSelector: {}
  ingress: []
```

After applying a deny policy, additional policies can be created to allow only the traffic required by the application.

## Restricting outbound access

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:

- Restricting access to approved SaaS platforms
- Limiting outbound internet connectivity
- Controlling access to internal APIs
- Preventing unauthorized data exfiltration

For advanced examples, see:

https://docs.cilium.io/en/stable/security/dns/

## Building Zero Trust networking

Network policies are one of the most effective ways to implement Zero Trust principles in Kubernetes.

A common adoption path is:

1. Gain visibility into traffic flows.
2. Identify communication requirements between services.
3. Create policies for critical workloads.
4. Gradually move toward least-privilege networking.
5. Continuously review and refine policies as applications evolve.

Network policies are most effective when combined with:

- Kubernetes RBAC
- OIDC authentication
- Service mesh-based mTLS
- Audit logging
- Workload hardening

For a broader overview, see [Zero Trust in Kubernetes](/docs/hetzner/apalla/security/zero-trust).

## Understanding traffic with Hubble

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:

- Which services are communicating?
- Which connections are being denied?
- Which workloads are generating unexpected traffic?
- Which DNS requests are being made?

This visibility is extremely valuable when designing and troubleshooting network policies.

See [Network Observability with Hubble](/docs/hetzner/apalla/security/hubble).

## Best practices

When implementing network policies, we recommend:

- Applying policies gradually
- Starting with critical applications and databases
- Using consistent workload labels
- Testing changes in non-production environments
- Monitoring traffic before enforcing restrictive rules

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.

## Additional resources

- [Cilium Security Documentation](https://docs.cilium.io/en/stable/security/)
- [Cilium Policy Documentation](https://docs.cilium.io/en/stable/security/policy/)
- [Cilium Network Policy Examples](https://docs.cilium.io/en/stable/security/policy/kubernetes/)
- [Cilium DNS Policies](https://docs.cilium.io/en/stable/security/dns/)

## Need help securing cluster networking?

Designing effective network policies requires understanding application communication patterns, security requirements, and operational tradeoffs.

The Syself team can help with:

- Cilium policy design
- Zero Trust networking
- Multi-tenant Kubernetes platforms
- Compliance-driven network segmentation
- Security reviews and hardening

If you would like assistance designing a secure Kubernetes networking architecture, [contact the Syself team](/demo).