Introduction

When you enable strict network isolation in Kubernetes, pods can lose access to DNS and other control plane adjacent services. The usual fix is a default deny policy plus narrow allow rules for traffic from kube-system. The important part is precision, because broad namespace trust can accidentally weaken security boundaries.

Understand Policy Direction Before Writing Rules

NetworkPolicy rules are directional. Ingress rules control who can reach selected pods. Egress rules control where selected pods can connect.

In many real outages, teams configure ingress allow rules for kube-system but forget egress DNS rules. That leaves pods unable to resolve names even though ingress looks correct.

Start with a clear matrix:

• which app pods are selected
• which source namespaces are allowed in ingress
• which destination namespaces and ports are allowed in egress

This avoids policy sprawl and accidental open paths.

Step 1: Apply Default Deny Baseline

Create a baseline deny policy in the target namespace.

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: default-deny-all
5  namespace: app
6spec:
7  podSelector: {}
8  policyTypes:
9    - Ingress
10    - Egress

With this policy alone, selected pods cannot receive or send traffic unless another policy allows it.

Step 2: Allow Required Traffic from kube-system

If your app needs ingress from system components, allow only that namespace first.

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: allow-ingress-from-kube-system
5  namespace: app
6spec:
7  podSelector: {}
8  policyTypes:
9    - Ingress
10  ingress:
11    - from:
12        - namespaceSelector:
13            matchLabels:
14              kubernetes.io/metadata.name: kube-system

This is simple but still broad. Use it only when the full namespace trust is justified.

Step 3: Narrow to Specific System Pods

A stronger policy selects only required system workloads, often CoreDNS.

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: allow-dns-from-kube-system
5  namespace: app
6spec:
7  podSelector: {}
8  policyTypes:
9    - Ingress
10  ingress:
11    - from:
12        - namespaceSelector:
13            matchLabels:
14              kubernetes.io/metadata.name: kube-system
15          podSelector:
16            matchLabels:
17              k8s-app: kube-dns

Label keys can differ by distribution, so inspect your cluster labels before applying.

Step 4: Add DNS Egress if Egress Is Restricted

If egress is denied, you must allow DNS from app pods to DNS pods.

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: allow-dns-egress
5  namespace: app
6spec:
7  podSelector: {}
8  policyTypes:
9    - Egress
10  egress:
11    - to:
12        - namespaceSelector:
13            matchLabels:
14              kubernetes.io/metadata.name: kube-system
15          podSelector:
16            matchLabels:
17              k8s-app: kube-dns
18      ports:
19        - protocol: UDP
20          port: 53
21        - protocol: TCP
22          port: 53

Without this rule, service discovery failures are expected in a locked down namespace.

Verification Workflow

Validate in a controlled order:

1. Check namespace labels and pod labels.
2. Confirm CNI plugin supports policy enforcement.
3. Apply baseline and allow policies in a staging namespace.
4. Run DNS and service connectivity tests from debug pods.

Useful commands:

1kubectl get ns --show-labels
2kubectl get pods -n kube-system --show-labels
3kubectl get networkpolicy -n app
4kubectl exec -it -n app deploy/myapp -- nslookup kubernetes.default.svc

If tests fail, inspect all policies together. Kubernetes combines allows across matching policies, which can produce unexpected final behavior.

Rollout and Change Management

For production hardening, avoid one large policy change. Roll out in phases:

• observe current traffic first
• apply baseline deny during low risk window
• add only required allow rules
• run smoke tests immediately
• monitor error rates and DNS failures

Document the reason for every allow rule in policy annotations or repository docs. Future reviewers need to know why each exception exists.

Common Pitfalls

A frequent mistake is assuming policy resources are enforced when the cluster CNI plugin does not implement enforcement fully.

Another problem is allowing all of kube-system forever when only DNS was needed. This broad trust can violate least privilege goals.

Teams also forget that policy selection is label based. A small label change can silently alter effective access.

Summary

• Start with default deny and then add explicit allow rules.
• Whitelist kube-system only as narrowly as your workload requires.
• Remember that egress DNS rules are mandatory in strict namespaces.
• Verify real labels and CNI behavior before debugging application code.
• Roll out policy changes gradually and test connectivity after each step.