Network security
Cloudfleet Kubernetes Engine (CFKE) secures cluster networking in layers. Cloudfleet manages some layers for you, such as encryption between nodes. You control other layers, such as the network policies that decide which workloads can talk to each other. This page explains what CFKE secures by default, which policy types are available, and which one to use for each goal.
CFKE uses Cilium as its container network interface (CNI). Cilium enforces network policies on every node, in public clouds and in your own data center. You do not need to enable or install anything.
Goals of network security on CFKE
Three principles guide a secure network setup on CFKE:
- Least privilege: allow only the communication your applications need. By default, Kubernetes lets every Pod reach every other Pod. Network policies turn this open network into an explicit allow-list.
- Defense in depth: combine independent controls, so that a single misconfiguration or a compromised workload does not expose the whole cluster. Encryption, network policies, and workload isolation each protect against different failures.
- Verifiable enforcement: observe the actual traffic and policy verdicts to confirm that your policies behave as intended.
What CFKE secures by default
The following protections are active on every CFKE cluster. They need no configuration.
| Layer | What it does |
|---|---|
| Node-to-node encryption | All traffic between nodes goes through WireGuard® tunnels, including traffic between nodes in the same private network or data center. See Networking architecture. |
| Policy enforcement | Cilium uses eBPF to enforce Kubernetes and Cilium network policies on every node, including self-managed nodes. |
| Identity-based filtering | Cilium identifies workloads by their labels, not their IP addresses. Your policies stay correct when Pods move between clouds and regions. |
| Flow visibility | Hubble records network flows and policy verdicts on every node. See Network observability with Hubble. |
Because the platform encrypts traffic between nodes, you do not need a service mesh only to encrypt Pod traffic in transit. Add a service mesh when you need mutual TLS identities between services or Layer 7 traffic management. For example, install Istio.
What the encryption covers
WireGuard® encrypts traffic between nodes and between nodes and the control plane. Traffic between two Pods on the same node never leaves the node. WireGuard® does not cover traffic that leaves the cluster, such as egress to the internet or traffic between clients and your load balancers. Protect this traffic with TLS.
Who manages what
| Component | Cloudfleet | You |
|---|---|---|
| Cilium | Installs, configures, and upgrades Cilium on every node. Announces version upgrades in the release notes. | Enable the self-service options in the Cloudfleet Console, such as socket load balancing in the host namespace only. |
| WireGuard® overlay | Creates the tunnels and manages the keys. | Allow the outbound connections that nodes need to join the cluster. |
| Network policies | Enforces every policy on every node. | Write and maintain the policies for your workloads and namespaces. |
| Hubble | Records flows on every node. | Deploy Hubble Relay and the Hubble UI when you need them. |
| Ingress and Gateway API | Creates cloud load balancers for LoadBalancer Services. | Install and operate your Ingress controller or Gateway API implementation. |
| Service mesh | Not included. | Install and operate a service mesh if you need mutual TLS or Layer 7 routing. |
Choose a network policy
Network traffic in a cluster falls into a few categories. Each category has a policy type that fits it best.
Pod-to-Pod traffic within the cluster
Most security requirements start here. For example, the frontend can reach the API, the API can reach the database, and nothing else can reach the database. Use a standard Kubernetes NetworkPolicy for these rules. It works on any Kubernetes distribution, applies to one namespace, and selects Pods by labels.
When you need more than Layer 3 and Layer 4 rules, use a CiliumNetworkPolicy. It supports everything a NetworkPolicy supports and adds two features:
- Layer 7 rules, for example to allow only
GETrequests to/api/*. - Predefined entities, for example the Kubernetes API server.
Egress to external services
Workloads often call external APIs, package registries, or managed databases. The IP addresses of these services change often, so CIDR-based rules break. A CiliumNetworkPolicy with toFQDNs rules allows egress by domain name, such as api.stripe.com or *.s3.amazonaws.com. Cilium keeps the allowed IP addresses in sync with the DNS answers.
If an external service allow-lists your source IP address, combine the policy with an egress gateway. Traffic then leaves the cluster from a predictable address.
Cluster-wide guardrails
Application teams own the policies in their namespaces. Platform and security teams usually need rules that apply to every namespace and that application teams cannot override. Examples are a block on cloud metadata endpoints, or the isolation of a regulated namespace.
Use a CiliumClusterwideNetworkPolicy for these rules. It has the same syntax as a CiliumNetworkPolicy, but applies to the whole cluster. Its deny rules take precedence over any allow rule in a namespace.
Untrusted workloads
Network policies limit what a workload can reach, but the workload still shares the node kernel with other Pods. For untrusted or AI-generated code, combine a default-deny policy with Kata Containers. Kata puts each Pod behind a virtual machine boundary.
Summary
| Goal | Recommended resource |
|---|---|
| Control Pod traffic by labels and namespaces | Kubernetes NetworkPolicy |
| Filter HTTP methods, paths, or headers | CiliumNetworkPolicy with Layer 7 rules |
| Control egress to external services by domain name | CiliumNetworkPolicy with toFQDNs |
| Enforce mandatory guardrails across all namespaces | CiliumClusterwideNetworkPolicy |
| Use a static source IP for outbound traffic | CiliumEgressGatewayPolicy |
| Encrypt traffic between nodes | Enabled by default with WireGuard® |
| Mutual TLS between services | A service mesh such as Istio |
| Audit allowed and dropped connections | Hubble |
How policies are evaluated
Cilium enforces Kubernetes NetworkPolicy, CiliumNetworkPolicy, and CiliumClusterwideNetworkPolicy resources. It combines them into a single rule set for each Pod:
- No policy selects the Pod: Cilium allows all traffic in that direction.
- At least one policy selects the Pod for ingress or egress: Cilium denies traffic in that direction unless a rule explicitly allows it. A policy with an empty rule list is therefore a default-deny.
- Allow rules are additive: if any policy allows a connection, Cilium allows it. The order in which you create policies does not matter.
- Deny rules win:
ingressDenyandegressDenyrules in aCiliumNetworkPolicyorCiliumClusterwideNetworkPolicyblock matching traffic, even if another policy allows it.
With this model, the platform team sets deny rules for the whole cluster, and application teams manage the allow rules in their own namespaces.
Audit and troubleshoot network policies
Hubble records every flow with its policy verdict. You see which connections Cilium forwarded, which it dropped, and why. To roll out a default-deny policy safely:
- Deploy the policy in a staging namespace.
- Watch for unexpected drops.
- Add the missing allow rules.
- Apply the policy in production.
For the commands, see Verify and troubleshoot policies. For common pitfalls, see Network connectivity issues.
What’s next
- Write your first policies with the examples in Network policies.
- Learn how traffic flows between nodes in Networking architecture.
- Route outbound traffic through a static IP with Egress gateways.
- Read the upstream references for Kubernetes network policies and Cilium network policies.
← Networking architecture