PS Product SecurityKnowledge Base

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.

Reveal the worked answer

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.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

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

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.

Reveal the worked answer

Real effect

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

Better version

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

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

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.

Reveal the worked answer

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.

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.

Reveal the worked answer

Right response

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

Example DNS allow

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

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?

Reveal the worked answer

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.