# Network Policy Patterns

![Network Policy Patterns](/files/quphmf9RZkLUwOLwFRtR)

> **Intro:** This page explains NetworkPolicy as a practical segmentation tool rather than a theoretical Kubernetes checkbox. It focuses on rollout patterns that reduce lateral movement while still respecting how real platform teams discover traffic, stage exceptions, and avoid outages.
>
> **What this page includes**
>
> * baseline patterns for default deny, app paths, egress, and shared services
> * rollout advice that keeps segmentation from turning into chaos
> * review questions that connect Kubernetes policy to the broader platform design
>
> **Working assumptions**
>
> * cluster networking is usually permissive by default, so segmentation has to be designed deliberately and introduced carefully

Kubernetes `NetworkPolicy` is one of the clearest examples of a control that is simple in YAML but hard in operations. The hard part is usually not syntax. The hard part is discovering real traffic, defining allowed flows, and managing exceptions without returning to a flat cluster.

## First reality check

Before relying on NetworkPolicy, confirm that your CNI actually enforces it. The API object alone does nothing without a network plugin that implements policy enforcement.

## Mental model

Use NetworkPolicy for **application-level segmentation at layer 3/4**.

It is best at:

* reducing easy east-west movement between workloads;
* making service dependencies explicit;
* shrinking the reachable set after pod compromise;
* documenting intended traffic flows close to the workload.

It is not a substitute for:

* RBAC and workload identity;
* admission policy;
* TLS and service authentication;
* cluster-admin guardrails;
* cloud-network segmentation outside the cluster.

## Recommended rollout sequence

### 1. Start with visibility and ownership

Before broad enforcement, identify:

* namespace owners;
* application-to-application dependencies;
* shared services such as DNS, ingress, service mesh, metrics, and logging;
* sensitive egress destinations such as metadata endpoints, secret stores, and external SaaS dependencies.

### 2. Apply namespace-level defaults

A strong baseline is to make the namespace model explicit.

#### Default deny ingress

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

#### Default deny egress

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
    - Egress
```

These defaults create a clean starting point: nothing talks unless you intentionally allow it.

### 3. Add named service paths

Name policies after business or platform flows, not after vague technical ideas. That makes reviews easier.

#### Example: allow frontend to backend

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-orders-api
spec:
  podSelector:
    matchLabels:
      app: orders-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              team: storefront
          podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8443
```

### 4. Keep shared-service exceptions explicit

Most segmentation rollouts fail because teams forget platform dependencies. Common examples include:

* cluster DNS;
* ingress or gateway controller paths;
* certificate managers;
* metrics and log collection agents;
* service-mesh control-plane traffic.

Create these as explicit, reusable policies rather than hidden one-off exceptions.

### 5. Add egress control for sensitive workloads

Egress policy is where the security value often jumps. It can reduce:

* secret exfiltration;
* data exfiltration;
* easy command-and-control callbacks;
* opportunistic lateral probing of internal services.

A staged rollout often works best: start with highly sensitive namespaces first, then expand.

## Common pattern library

| Pattern                            | Use it when                                                     | What to watch                                        |
| ---------------------------------- | --------------------------------------------------------------- | ---------------------------------------------------- |
| Default deny ingress               | any namespace with meaningful isolation goals                   | make platform paths explicit                         |
| Default deny egress                | sensitive workloads, regulated data, admin components           | do not forget DNS and required external services     |
| Frontend to backend allow          | app-to-app service path                                         | label hygiene matters                                |
| Ingress controller to app          | internet or edge traffic reaches workloads through a controller | scope source namespaces carefully                    |
| Namespace to namespace allow       | multi-service trust relationship                                | avoid re-creating flat trust by over-broad selectors |
| Egress to external CIDR or service | known external dependency                                       | keep exception ownership clear                       |

## Important limits and caveats

* NetworkPolicy is primarily a layer 4 construct.
* Behavior outside TCP, UDP, and SCTP may vary by network plugin.
* Policy without enforcement support in the CNI has no practical effect.
* A pod cannot use NetworkPolicy to block access to itself.
* Node-local, host-network, and cloud-network realities still matter outside the policy object.

## Review questions

1. Which namespaces still have no default-deny baseline?
2. Which policies describe real business flows, and which are vague or over-broad?
3. Are ingress and egress both considered, or only inbound paths?
4. Can a compromised workload still reach unrelated services by default?
5. Are platform exceptions tracked and reviewed like any other privileged dependency?
6. How do cloud segmentation, ingress design, and service identity align with the policy set?

## Common anti-patterns

* turning on cluster-wide default deny with no traffic discovery;
* allowing all egress because “the application needs the internet”;
* using broad namespace selectors that silently recreate flat connectivity;
* forgetting that identity and admission controls still matter after segmentation;
* never deleting temporary policy exceptions.

## Strong target state

A strong target state is not “the most policies.” It is a cluster where:

* namespaces start isolated by default;
* allowed paths are named and reviewable;
* sensitive egress is deliberate;
* platform exceptions are visible debt, not invisible magic.

## Related pages

* [Kubernetes Hardening](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-hardening.md)
* [AWS Networking and Policy Baseline](https://github.com/D3One/Product-Security-Gitbook/blob/main/08-infrastructure-and-cloud-security/aws-networking-and-policy-baseline.md)
* [Cloud Attack Chains](/attack-paths-testing-detection-and-hardening/index-1/cloud-attack-chains.md)
* [Kubernetes Baseline](/learning-labs-interview-and-templates/index/kubernetes-baseline.md)

## Suggested reference links

* [Kubernetes NetworkPolicy concepts](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
* [Kubernetes services and networking overview](https://kubernetes.io/docs/concepts/services-networking/)

***

*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/cloud-kubernetes-and-infrastructure-security/index-1/network-policy-patterns.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.