Deploy network policies with CKS

This tutorial demonstrates how to implement basic network policies on CoreWeave Kubernetes Service (CKS) clusters to segment and secure Pod-to-Pod communication. By the end, you have a working default-deny network policy and a targeted allow rule, validated with test Pods. You’ll learn the rationale behind each step, CoreWeave-specific best practices, and how to validate your configuration. This tutorial is for platform engineers and cluster operators who need to enforce Pod-level network segmentation on CKS.

Prerequisites

CKS cluster: You need access to a CKS cluster. CKS runs on bare-metal nodes with hardware isolation (NVIDIA BlueField-3 DPU) and uses the Cilium CNI by default for high-performance, eBPF-powered policy enforcement.
kubectl access: Ensure kubectl is installed and configured for your cluster identity and namespace.

Create or use an existing namespace

Namespaces provide logical segmentation and isolation in Kubernetes. They are foundational for multi-tenancy and enforcing network policies scoped to individual teams or workloads. This step ensures your resources don’t interfere with others and that network policies apply only within your segment. Replace [NAMESPACE] in the following examples with a name relevant to your application.

kubectl create ns [NAMESPACE]

With a namespace ready, the next step is to deploy the Pods that your network policies govern.

Deploy sample Pods

Deploy two Pods:

backend: an NGINX server exposing port 80, labeled app: backend.
frontend: a BusyBox Pod running sleep, labeled app: frontend.

These two Pods let you demonstrate segmentation: by restricting which Pods can reach backend, you exercise least privilege for service access.

kubectl apply -n [NAMESPACE] -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: backend
  labels:
    app: backend
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: frontend
  labels:
    app: frontend
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]
EOF

After applying this manifest, both Pods should be running in your namespace. Now that you have workloads in place, you can define the network policies that control traffic between them.

Create a default deny policy for your namespace

By default, Pods in Kubernetes can communicate freely. CoreWeave mitigates this with a defense-in-depth architecture (hardware isolation, Cilium default policies), but you should still apply explicit Kubernetes network policies for application-level segmentation. This policy blocks all ingress and egress traffic to Pods in the namespace unless specifically permitted:

kubectl apply -n [NAMESPACE] -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
EOF

This policy implements a “default deny” posture essential for microsegmentation and preventing lateral movement if a Pod is compromised. CoreWeave’s network architecture offloads kernel-level filtering to Cilium using eBPF. The DPU hardware enforces policies close to the network interface. With the default-deny policy applied, all Pod traffic in the namespace is now blocked. The next step is to selectively allow the specific traffic your application requires.

Create an allow policy for frontend to backend access

This policy allows only the frontend Pod to access the backend Pod on any port. No other Pod in the namespace, nor from outside, can reach backend.

kubectl apply -n [NAMESPACE] -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
EOF

This policy targets the backend Pod and allows ingress traffic only from Pods labeled app: frontend within the same namespace. All other traffic remains denied, implementing the principle of least privilege where only specifically required connections are permitted. At this point, your namespace has both a default-deny policy and a targeted allow rule. The following section confirms that these policies work as expected.

CKS-specific considerations

New CKS clusters run Cilium as the CNI (a small number of older clusters still run Calico), and a few details differ from generic Cilium examples. Apply these rules so that a default-deny policy doesn’t accidentally block platform access. For the full reference, see Cilium network policy on CKS: cluster-specific patterns.

Allow the CoreWeave platform services CIDR. A default-deny policy must allow egress to 100.124.0.0/18. This range covers the Kubernetes API server, cluster DNS, and other CoreWeave-managed infrastructure. Without it, kubectl access and DNS resolution break.
Target node-local-dns for DNS egress, not kube-dns. CKS uses NodeLocal DNSCache. In a CiliumNetworkPolicy, the DNS egress selector must use the k8s: label prefix:
egress: - toEndpoints: - matchLabels: k8s:k8s-app: node-local-dns k8s:io.kubernetes.pod.namespace: kube-system
Omitting the k8s: prefix or targeting kube-dns doesn’t match on CKS.
toFQDN rules require a Layer 7 feature flag. Egress rules that match a fully qualified domain name use Cilium’s Layer 7 DNS proxy, which depends on the enable-bpf-tproxy setting being false. You can’t change this yourself. Open a support ticket to request it for your cluster. Applying a toFQDN policy before the flag is set can break DNS resolution entirely.
Roll out with audit mode first. Cilium audit mode logs policy violations without enforcing them, so you can validate a policy against real traffic before enforcing it. To enable audit mode, see Cilium network policy on CKS: cluster-specific patterns.

Validate your network policies

Validation is crucial to ensure your policies have the intended effect. Here’s how to test and confirm enforcement:

Enter the frontend Pod and attempt to reach backend:
kubectl exec -n [NAMESPACE] frontend -- sh -c "wget -qO- http://backend:80"
You should receive the NGINX welcome message.
Deploy a third Pod to test isolation:
kubectl run other --rm -i -t -n [NAMESPACE] --image=busybox --restart=Never -- sh
Inside this shell, run:
wget -qO- http://backend:80
The connection should be refused or time out, demonstrating that only frontend has access.
Confirm logs and network policy enforcement: Check that your network policies are active and enforced:
# Verify network policies are created and active kubectl get networkpolicy -n [NAMESPACE] # Check detailed policy status kubectl describe networkpolicy deny-all -n [NAMESPACE] kubectl describe networkpolicy allow-frontend-to-backend -n [NAMESPACE]
You should see both policies listed as active, with the correct Pod selectors and rules configured. To observe policy enforcement in action:
# Watch Cilium logs during your test connections kubectl logs -n kube-system -l k8s-app=cilium --tail=50 -f
When you run the connection tests from steps 1 and 2, you should see log entries showing allowed connections from frontend and dropped connections from unauthorized Pods.

With your network policies in place and validated, you’ve implemented microsegmentation that uses CoreWeave’s hardware-accelerated Cilium CNI for efficient policy enforcement at the DPU level. This provides application-layer security controls that complement the platform’s built-in hardware isolation, with observability available through Cilium’s metrics and logs. For deeper audit capabilities, CoreWeave supports tools like Cilium Tetragon for eBPF-based observability and Falco for runtime threat detection.

​Prerequisites

​Create or use an existing namespace

​Deploy sample Pods

​Create a default deny policy for your namespace

​Create an allow policy for frontend to backend access

​CKS-specific considerations

​Validate your network policies