# Network Policy Assessment Pack

> **Intro:** These tasks focus on Kubernetes NetworkPolicy reasoning. The point is not YAML memorization. The point is whether the candidate can translate intended traffic into an enforceable policy set and spot where isolation assumptions are wrong.

## Task 1 - Team thinks namespaces isolate by themselves

### Scenario

The platform team split workloads into `frontend`, `payments`, and `ops` namespaces. No NetworkPolicy objects exist.

### Prompt

Explain why the design is still open by default and what the first two policies should be.

<details>

<summary><strong>Reveal the worked answer</strong></summary>

#### Core point

Namespaces organize resources, but they do not isolate traffic by themselves. Without NetworkPolicy enforcement and a supporting CNI, traffic is usually broadly allowed.

#### First two policies

1. a default-deny ingress/egress baseline for application namespaces;
2. explicit allow rules for DNS and required app-to-app communication.

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
```

</details>

## Task 2 - Policy allows too much because selectors are too broad

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-frontend
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
    - from:
        - namespaceSelector: {}
```

### Prompt

What is the real effect of this policy? Fix it.

<details>

<summary><strong>Reveal the worked answer</strong></summary>

#### Real effect

`namespaceSelector: {}` matches all namespaces. This is not “frontend only.” It allows ingress from any namespace.

#### Better version

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-frontend
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: frontend
          podSelector:
            matchLabels:
              app: web
      ports:
        - protocol: TCP
          port: 8443
```

</details>

## Task 3 - Egress left unrestricted because “ingress is the real risk”

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ingress-only
  namespace: app
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
```

### Prompt

Why is this incomplete? Give an example of what an attacker can still do.

<details>

<summary><strong>Reveal the worked answer</strong></summary>

#### Incomplete because

The policy restricts ingress only. Egress is still unconstrained unless other policies cover it.

#### Attacker example

A compromised backend pod can still:

* beacon to an external C2 endpoint;
* scan internal services;
* call cloud metadata or internal package registries;
* exfiltrate data to external destinations.

#### Better direction

Add egress policy and allow only required destinations such as DNS, specific namespaces, or approved external endpoints.

</details>

## Task 4 - Service-to-service traffic breaks after default deny, and the team wants to remove policy entirely

### Scenario

After applying default deny, the app cannot resolve DNS and metrics shipping fails.

### Prompt

What is the right response? Show one example policy addition.

<details>

<summary><strong>Reveal the worked answer</strong></summary>

#### Right response

Do not remove the baseline. Add narrowly scoped allows for necessary shared services.

#### Example DNS allow

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: app
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
```

</details>

## Task 5 - Policy written for Pods, but the risk is through a Service or external exposure

### Scenario

A Service exposes the `payments-api` through a `LoadBalancer`. The team says their internal NetworkPolicy means the API is protected.

### Prompt

Why is that reasoning incomplete?

<details>

<summary><strong>Reveal the worked answer</strong></summary>

#### Key point

NetworkPolicy governs Pod traffic at the CNI layer. Exposure through `LoadBalancer`, ingress controllers, cloud firewalls, or external service configuration still needs to be reviewed separately.

#### Better answer

Review together:

* Service type;
* ingress controller policy;
* TLS and authn/authz at the app edge;
* cloud security groups / firewall rules;
* NetworkPolicy for east-west traffic.

</details>


---

# 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/learning-labs-interview-and-templates/index-1/network-policy-assessment-pack.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.