> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy network policies with CKS

> Enforce Pod-level network segmentation on CKS clusters.

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.

```bash theme={"system"}
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.

```bash theme={"system"}
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:

```bash theme={"system"}
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`.

```bash theme={"system"}
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](/products/networking/cilium-network-policy-cks-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:

  ```yaml theme={"system"}
  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](/products/networking/cilium-network-policy-cks-patterns).

## Validate your network policies

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

1. Enter the `frontend` Pod and attempt to reach `backend`:

   ```bash theme={"system"}
   kubectl exec -n [NAMESPACE] frontend -- sh -c "wget -qO- http://backend:80"
   ```

   You should receive the NGINX welcome message.

2. Deploy a third Pod to test isolation:

   ```bash theme={"system"}
   kubectl run other --rm -i -t -n [NAMESPACE] --image=busybox --restart=Never -- sh
   ```

   Inside this shell, run:

   ```bash theme={"system"}
   wget -qO- http://backend:80
   ```

   The connection should be refused or time out, demonstrating that only `frontend` has access.

3. Confirm logs and network policy enforcement:

   Check that your network policies are active and enforced:

   ```bash theme={"system"}
   # 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:

   ```bash theme={"system"}
   # 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](/security/tutorials/ebpf-observability) and Falco for runtime threat detection.