Kubernetes Network Policies Setup for Network Isolation

For a production cluster with 5 microservices, about 10 policies are needed. Each includes Ingress and Egress rules. Below is a template for a typical service with a database and cache:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: service-a
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: service-a
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx
      ports:
        - port: 3000
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - port: 5432
    - to:
        - podSelector:
            matchLabels:
              app: redis
      ports:
        - port: 6379
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - port: 53
          protocol: UDP
        - port: 53
          protocol: TCP

Important: in modern Kubernetes versions, namespaceSelector and podSelector in the same from block are treated as AND. In older versions — as OR. Check your cluster version, e.g., kubectl version --short.

Cross-namespace communication: allow-prometheus-scrape

For example, a monitoring namespace needs to scrape metrics from pods in production. We create an allow policy in the production namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-prometheus-scrape
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: monitoring
          podSelector:
            matchLabels:
              app.kubernetes.io/name: prometheus
      ports:
        - port: 9090
          protocol: TCP

The healthcheck problem and its solution

kubelet performs health probes from the node IP (node IP) to the pod. If policies block incoming traffic from any sources, kubelet cannot execute probes. Solution: allow traffic from the cluster node CIDR:

 ingress: - from: - ipBlock: cidr: 10.0.0.0/16 # CIDR of cluster nodes ports: - port: 8080 

This prevents 95% of healthcheck issues after policy implementation.

How to debug Network Policies?

The difficulty lies in the absence of block logs in Kubernetes itself. Use specialized tools:

• Calico: calicoctl get policy -n production shows parsed rules; calicoctl node diags collects dataplane state.
• Cilium: cilium monitor --type drop displays dropped packets; hubble observe --namespace production --verdict DROPPED provides statistics via Hubble UI. Cilium is one of the most performant CNI plugins with eBPF.

Without utilities: run a pod with the image nicolaka/netshoot and test using nc -zv postgres 5432.

Comparison of CNI plugins for Network Policies

Cilium is 2-3 times faster than Calico at L7 filtering thanks to eBPF. For most production scenarios, Calico is sufficient, but if deep observability and high performance are needed, choose Cilium. Flannel without addons does not support policies, so do not consider it for isolation.

Step-by-step Network Policy setup

1. Audit current network topology and security model — identify namespaces and services.
2. Design policies based on flows: Ingress from Ingress controller, Egress to databases.
3. Develop manifests covering all critical flows (don't forget DNS!).
4. Test on a staging environment — check healthchecks, DNS, and application functionality.
5. Document each policy and isolation scheme for the operations team.

Typical problems and mistakes with Network Policies

Most often (95% of cases), healthcheck is blocked — always add ipBlock for nodes. Also forgetting Egress to DNS and replication between StatefulSet replicas. Use kubectl describe networkpolicy to verify.

What is included in the work

• Audit of current network topology and threat model.
• Design of isolation policies for your stack (Calico/Cilium).
• Writing and applying manifests (default deny + allow rules).
• Testing all critical flows (healthcheck, DNS, monitoring).
• Documentation of isolation scheme and runbook for operations team.
• Training engineers on policy management (2-hour workshop).
• Post-deployment support for 2 weeks.
• Access to private repository with policy templates.

Deliverables include: finalized NetworkPolicy manifests, comprehensive documentation, training session, and post-deployment support. We guarantee a smooth rollout with no downtime and provide a 100% satisfaction guarantee.

Standard project cost for setting up Network Policies — from $700–1.5k depending on complexity and number of services.

Timelines

• Simple cluster (3-5 services in one namespace) — 1-2 days.
• Complex topology with cross-namespace communication — up to 3 days.
• Full audit and production implementation (including documentation) — from 4 days.

Contact our engineers for an audit of your cluster — we will calculate timelines and scope for your project. Order turnkey Network Policy implementation: ensure security without downtime.

Source: Kubernetes Documentation