Network policies for security in Kubernetes - Commands & Configuration

Introduction

Network policies control how groups of pods communicate with each other and with other network endpoints. They help keep your Kubernetes applications safe by limiting which pods can talk to which, reducing the risk of unwanted access.

When you want to allow only specific pods to access a database pod to protect sensitive data.

When you need to block all incoming traffic to a pod except from trusted pods in the same namespace.

When you want to restrict external access to only certain services in your cluster.

When you want to isolate different teams' applications running in the same Kubernetes cluster.

When you want to enforce security rules that prevent pods from communicating with unknown or untrusted pods.

Config File - network-policy.yaml

network-policy.yaml

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

This file defines a NetworkPolicy named allow-frontend-to-backend in the default namespace.

The podSelector selects pods with label app: backend to apply the policy to.

The policyTypes field specifies this policy controls incoming traffic (Ingress).

The ingress rule allows traffic only from pods labeled app: frontend on TCP port 80.

Commands

This command creates the network policy in the Kubernetes cluster to restrict backend pods to only accept traffic from frontend pods on port 80.

Terminal

kubectl apply -f network-policy.yaml

Expected Output

networkpolicy.networking.k8s.io/allow-frontend-to-backend created

This command retrieves the details of the created network policy to verify it was applied correctly.

Terminal

kubectl get networkpolicy allow-frontend-to-backend -o yaml

Expected Output

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

  name: allow-frontend-to-backend

  namespace: default

spec:

  ingress:

  - from:

    - podSelector:

        matchLabels:

          app: frontend

    ports:

    - protocol: TCP

      port: 80

  podSelector:

    matchLabels:

      app: backend

  policyTypes:

  - Ingress

→

-o yaml - Outputs the network policy details in YAML format for easy reading

This command shows a human-readable description of the network policy, including which pods it selects and the allowed traffic rules.

Terminal

kubectl describe networkpolicy allow-frontend-to-backend

Expected Output

Name:         allow-frontend-to-backend

Namespace:    default

Labels:       <none>

Annotations:  <none>



PodSelector:  app=backend

PolicyTypes:  Ingress



Ingress:

  From:

    PodSelector: app=frontend

  Ports:

    Protocol: TCP Port: 80

Key Concept

If you remember nothing else from this pattern, remember: network policies let you control which pods can talk to each other to improve security.

Common Mistakes

Not specifying podSelector in the network policy spec

Without podSelector, the policy does not apply to any pods, so no traffic is restricted.

Always include podSelector to target the pods you want to protect.

Forgetting to specify policyTypes when creating ingress or egress rules

Kubernetes defaults to no traffic restrictions unless policyTypes are set, so rules may not take effect.

Always set policyTypes to Ingress, Egress, or both depending on your rules.

Allowing traffic from all pods by using an empty from field

This defeats the purpose of restricting traffic and leaves pods open to all connections.

Specify podSelector or namespaceSelector in from to limit allowed sources.

Summary

Create a network policy YAML file that selects target pods and defines allowed traffic sources and ports.

Apply the network policy using kubectl apply to enforce traffic restrictions.

Verify the policy with kubectl get and kubectl describe commands to ensure it is correctly applied.

Practice

1. What is the main purpose of a Kubernetes NetworkPolicy?

easy

A. To update container images automatically

B. To schedule pods on specific nodes

C. To manage storage volumes for pods

D. To control which pods can communicate with each other

Solution

1. Step 1: Understand NetworkPolicy role

   A NetworkPolicy defines rules about pod communication inside a Kubernetes cluster.

2. Step 2: Identify main function

   It controls which pods can send or receive network traffic to improve security.

3. Final Answer:

   To control which pods can communicate with each other -> Option D

4. Quick Check:

   NetworkPolicy controls pod communication = A [OK]

Hint: NetworkPolicy controls pod communication, not scheduling or storage [OK]

Common Mistakes:

• Confusing NetworkPolicy with pod scheduling
• Thinking NetworkPolicy manages storage
• Assuming NetworkPolicy updates images

2. Which of the following is the correct way to specify a pod selector in a NetworkPolicy YAML?

easy

A. podSelector: labels: role: frontend

B. podSelector:
matchLabels:
role: frontend

C. podSelector: role=frontend

D. podSelector: role: frontend

Solution

1. Step 1: Recall podSelector syntax

   In NetworkPolicy YAML, podSelector uses matchLabels to select pods by labels.

2. Step 2: Match correct YAML format

   podSelector: matchLabels: role: frontend correctly uses podSelector with matchLabels syntax.

3. Final Answer:

   podSelector: matchLabels: role: frontend -> Option B

4. Quick Check:

   Correct podSelector uses matchLabels = C [OK]

Hint: Use matchLabels map inside podSelector for correct syntax [OK]

Common Mistakes:

• Using incorrect YAML indentation
• Omitting matchLabels key
• Writing labels without proper mapping

3. Given this NetworkPolicy snippet, what traffic is allowed?

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 80

medium

A. Only pods with label role=frontend can access nginx pods on TCP port 80

B. All pods can access nginx pods on any port

C. Only pods with label app=nginx can access frontend pods on port 80

D. No traffic is allowed to nginx pods

Solution

1. Step 1: Analyze podSelector and ingress rules

   The policy selects pods with label app: nginx and allows ingress only from pods with role: frontend on TCP port 80.

2. Step 2: Interpret allowed traffic

   Only pods labeled role=frontend can connect to nginx pods on TCP port 80; other traffic is blocked.

3. Final Answer:

   Only pods with label role=frontend can access nginx pods on TCP port 80 -> Option A

4. Quick Check:

   Ingress from role=frontend on port 80 = B [OK]

Hint: Ingress from podSelector limits source pods and ports [OK]

Common Mistakes:

• Assuming all pods can access nginx
• Confusing source and destination labels
• Ignoring port restrictions

4. You wrote this NetworkPolicy but pods labeled role=frontend still cannot access app=nginx pods on port 80. What is wrong?

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

medium

A. The metadata name is incorrect

B. The podSelector is missing in the policy

C. The port in the policy is 8080 but nginx listens on port 80

D. The protocol TCP is not supported in NetworkPolicy

Solution

1. Step 1: Compare port in policy with actual service port

   The policy allows ingress on TCP port 8080, but nginx usually listens on port 80.

2. Step 2: Identify mismatch causing blocked traffic

   Because the port does not match nginx's listening port, traffic is blocked despite correct podSelector.

3. Final Answer:

   The port in the policy is 8080 but nginx listens on port 80 -> Option C

4. Quick Check:

   Port mismatch blocks traffic = D [OK]

Hint: Check port numbers match service and policy exactly [OK]

Common Mistakes:

• Ignoring port mismatch
• Assuming protocol TCP is unsupported
• Thinking metadata name affects traffic

5. You want to create a NetworkPolicy that allows pods labeled role=frontend to access pods labeled app=nginx on port 80, but blocks all other traffic. Which YAML snippet correctly achieves this?

hard

A. spec:
podSelector:
matchLabels:
app: nginx
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 80

B. spec:
podSelector:
matchLabels:
role: frontend
ingress:
- from:
- podSelector:
matchLabels:
app: nginx
ports:
- protocol: TCP
port: 80

C. spec:
podSelector:
matchLabels:
app: nginx
egress:
- to:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 80

D. spec:
podSelector:
matchLabels:
app: nginx
ingress:
- from:
- namespaceSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 80

Solution

1. Step 1: Identify pods to protect and allowed sources

   The policy must select pods with app: nginx and allow ingress only from pods with role: frontend.

2. Step 2: Check ingress rules and ports

   spec: podSelector: matchLabels: app: nginx ingress: - from: - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 80 correctly uses podSelector for nginx pods and allows ingress from frontend pods on TCP port 80.

3. Step 3: Confirm other options are incorrect

   The snippet that selects role: frontend in podSelector but has from app: nginx reverses source and destination; the snippet using egress and to controls outgoing traffic; the snippet using namespaceSelector selects entire namespaces instead of specific pods.

4. Final Answer:

   spec: podSelector: matchLabels: app: nginx ingress: - from: - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 80 -> Option A

5. Quick Check:

   Correct podSelector and ingress from frontend pods = A [OK]

Hint: Select nginx pods and allow ingress from frontend pods on port 80 [OK]

Common Mistakes:

• Mixing up podSelector labels
• Using egress instead of ingress
• Using namespaceSelector instead of podSelector