How to Use Kubernetes Network Policies to Control Pod Communication

The policy does not create a listener on port 8080. The backend application must actually listen on that port for connections to succeed.

Step 4: Restrict Access to the Database

Now suppose only backend pods should connect to the database on TCP port 5432.

Create a policy in the database namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-database
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: backend
          podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 5432

Apply the policy:

kubectl apply -f allow-backend-to-database.yaml

The policy allows matching backend pods to connect to the selected database pods on TCP port 5432.

Other incoming connections to those database pods are denied by this policy only if the pods are isolated for ingress and no other applicable NetworkPolicy permits the traffic.

For a secure design, review all policies that select the database pods. Since policies are additive, another policy that allows broader traffic could also permit connections.

Step 5: Deny Unwanted Incoming Traffic

A common security requirement is to deny incoming traffic by default and then allow only the connections that are needed.

You can create a default-deny ingress policy in a namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: database
spec:
  podSelector: {}
  policyTypes:
    - Ingress

This policy selects all pods in the database namespace and isolates them for ingress. No incoming connections are permitted unless another applicable NetworkPolicy allows them.

Because policies are additive, the allow-backend-to-database policy can still permit the intended backend traffic.

Be careful when applying default-deny policies to existing namespaces. They can break application traffic, health checks, monitoring, or other required connections if the necessary allow rules are missing.

Also, default-deny ingress does not restrict outgoing connections. Egress needs its own policy.

Step 6: Control Outgoing Traffic with Egress Policies

Ingress policies control traffic entering selected pods. Egress policies control traffic leaving selected pods.

For example, a backend application might need to connect to the database but should not be allowed to send traffic to arbitrary destinations.

An egress policy can allow the backend pods to connect to the database namespace on port 5432:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-to-database
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: database
          podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 5432

This isolates selected backend pods for egress and allows the specified database traffic.

Once egress isolation is enabled, other outgoing traffic is denied unless another applicable policy allows it. The backend may also need access to DNS, authentication services, external APIs, or telemetry endpoints.

If those dependencies are required, add explicit rules for them. Otherwise, the application may be unable to resolve service names or contact external systems.

Step 7: Verify That the Policies Work

After applying the policies, check that the resources exist:

kubectl get networkpolicy -A

Inspect a specific policy:

kubectl describe networkpolicy allow-backend-to-database \
  -n database

Check the pod labels and namespace assignments:

kubectl get pods -n backend --show-labels
kubectl get pods -n database --show-labels

You can also inspect the standard namespace labels:

kubectl get namespace frontend --show-labels
kubectl get namespace backend --show-labels
kubectl get namespace database --show-labels

For an actual connectivity test, use pods that have a suitable network diagnostic tool and an application listening on the target port.

For example, if the backend contains a shell and curl, you might test an HTTP endpoint from the backend namespace. The destination should be the database service or pod endpoint appropriate to your environment, and the test protocol must match the application.

Do not rely on the sample NGINX database pod to prove connectivity on port 5432. It does not run a PostgreSQL server.

If a connection fails, check the NetworkPolicy rules, pod and namespace labels, actual listening ports, routing, service configuration, and network plugin behavior.

Common Mistakes to Avoid

Assuming namespaces block traffic automatically

Namespaces provide organization, not automatic network isolation. Use NetworkPolicies and verify that your network plugin enforces them.

Selecting the wrong pods

A policy affects only the pods matched by its podSelector. If labels do not match, the intended policy may not protect the workload.

Misunderstanding selector logic

A namespaceSelector and podSelector in the same item under from or to must both match. Separate items in the list represent alternative allowed sources or destinations.

Forgetting that policies are additive

A restrictive policy does not cancel an allow rule from another applicable policy. Review all policies that select the same pods.

Blocking DNS or required services

Default-deny egress policies can prevent DNS lookups and outbound API calls. Add rules for the required destinations and ports.

Assuming the port declaration starts a service

A NetworkPolicy permits or denies traffic; it does not configure the application to listen on a port. The container and service must use the correct ports.

Ignoring network plugin support

The existence of a NetworkPolicy object does not prove that traffic is being enforced. Confirm that the installed networking implementation supports NetworkPolicies.

Best Practices for Production Clusters

• Separate workloads by namespace where it helps define clear security boundaries.
• Use stable, meaningful pod labels in NetworkPolicies.
• Start with default-deny policies where appropriate, then allow only required traffic.
• Review both ingress and egress requirements.
• Permit necessary DNS, monitoring, health-check, and external service traffic.
• Keep policies under version control and review them with application changes.
• Test allowed and denied connections before production deployment.
• Audit all policies that select sensitive workloads.
• Confirm network plugin support and enforcement.
• Combine network isolation with authentication, authorization, and application-level security.

Summary

Kubernetes NetworkPolicies let you control communication between selected pods using labels, namespaces, ports, and traffic direction.

By allowing frontend traffic to the backend and restricting database access to backend workloads, you can reduce unnecessary communication inside a cluster.

A reliable implementation requires more than applying YAML. Check selector logic, account for additive policies, allow required dependencies, and verify actual network behavior. When used carefully, NetworkPolicies provide an important layer of network isolation for Kubernetes applications.