Backend interview prep

Start Learning

OpenShift Network Policies

Learn how Network Policies secure communication between Pods in OpenShift. Understand ingress, egress, namespace isolation, Spring Boot microservices, and enterprise zero-trust networking.

Introduction

One of the biggest security risks in Kubernetes and OpenShift environments is unrestricted Pod-to-Pod communication.

By default, Pods inside the same cluster can communicate with each other. While this simplifies application development, it also introduces security concerns.

Imagine a cluster hosting:

  • Payment Service
  • Customer Service
  • Loan Service
  • Fraud Detection
  • Notification Service

Should every Pod be able to communicate with every other Pod?

No.

For example:

  • Payment Service should communicate with Fraud Service.
  • Notification Service should receive events from Payment Service.
  • Customer Service should not directly access the Payment database.
  • Unknown Pods should never communicate with internal business services.

OpenShift provides Network Policies to implement Zero Trust Networking, allowing communication only between explicitly authorized Pods.

Learning Objectives

By the end of this article, you will understand:

  • What are Network Policies?
  • Why Network Policies are important
  • Ingress Policies
  • Egress Policies
  • Namespace Isolation
  • Spring Boot Microservice Security
  • Zero Trust Networking
  • Enterprise Network Design
  • Best Practices

Why Network Policies?

Without Network Policies every Pod can communicate with every other Pod.

flowchart LR
A[Payment Service]

B[Customer Service]

C[Loan Service]

D[Notification Service]

E[Fraud Service]

A --> B
A --> C
A --> D
A --> E

B --> A
B --> C
B --> D
B --> E

C --> A
C --> B
C --> D
C --> E

This creates unnecessary attack paths.

Secure Communication

Using Network Policies

flowchart LR

Payment

Fraud

Notification

Customer

Loan

Payment --> Fraud

Payment --> Notification

Customer --> Payment

Loan -. Blocked .-> Payment

Only approved communication is allowed.

What is a Network Policy?

A Network Policy is a Kubernetes/OpenShift resource that controls network communication between Pods.

It defines:

  • Which Pods can communicate
  • Allowed incoming traffic
  • Allowed outgoing traffic
  • Namespace communication
  • Port restrictions

Network Policy Architecture

flowchart TD
    CLIENT["Client"]
    ROUTE["Route"]
    API["API Gateway"]

    PAYMENT["Payment Service"]
    FRAUD["Fraud Service"]
    NOTIFY["Notification Service"]
    CUSTOMER["Customer Service"]

    CLIENT --> ROUTE
    ROUTE --> API
    API --> PAYMENT

    PAYMENT --> FRAUD
    PAYMENT --> NOTIFY

    CUSTOMER -. "Blocked" .-> FRAUD

Default Communication

Without a Network Policy

flowchart LR

Pod1 --> Pod2

Pod1 --> Pod3

Pod1 --> Pod4

Pod2 --> Pod3

Pod2 --> Pod4

Pod3 --> Pod4

Everything is allowed.

Zero Trust Model

With Network Policies

flowchart LR

Payment

--> Fraud

Payment

--> Notification

Customer

--> Payment

Fraud

-. Denied .-> Customer

Every connection must be explicitly allowed.

Types of Network Policies

Policy Description
Ingress Controls incoming traffic
Egress Controls outgoing traffic
Both Complete network isolation

Ingress Policy

Ingress controls who can access your application.

flowchart LR
    CUSTOMER["Customer"]
    FRAUD["Fraud Service"]
    UNKNOWN["Unknown Pod"]
    PAYMENT["Payment Service"]

    CUSTOMER --> PAYMENT
    FRAUD --> PAYMENT
    UNKNOWN -. "Blocked" .-> PAYMENT

Ingress YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy

metadata:
  name: payment-ingress

spec:

  podSelector:

    matchLabels:

      app: payment

  policyTypes:

  - Ingress

Egress Policy

Egress controls where a Pod can send requests.

flowchart LR
    PAYMENT["Payment Service"]
    POSTGRES["PostgreSQL"]
    KAFKA["Kafka"]
    INTERNET["Internet"]

    PAYMENT --> POSTGRES
    PAYMENT --> KAFKA
    PAYMENT -. "Blocked" .-> INTERNET

Egress YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy

metadata:
  name: payment-egress

spec:

  podSelector:

    matchLabels:

      app: payment

  policyTypes:

  - Egress

Ingress + Egress

flowchart LR
    CUSTOMER["Customer"]
    PAYMENT["Payment Service"]
    DB["Database"]
    KAFKA["Kafka"]
    INTERNET["Internet"]

    CUSTOMER --> PAYMENT
    PAYMENT --> DB
    PAYMENT --> KAFKA

    INTERNET -.->|Blocked| PAYMENT

Spring Boot Architecture

flowchart TD
    ROUTE["Route"]
    API["API Gateway"]

    CUSTOMER["Customer Service"]
    PAYMENT["Payment Service"]
    FRAUD["Fraud Service"]
    NOTIFY["Notification Service"]
    DB["PostgreSQL"]

    ROUTE --> API

    API --> CUSTOMER
    API --> PAYMENT

    PAYMENT --> FRAUD
    PAYMENT --> NOTIFY
    PAYMENT --> DB

Network Policies secure every communication path.

Banking Example

flowchart LR
    CUSTOMER["Customer"]
    API["API Gateway"]
    PAYMENT["Payment Service"]
    FRAUD["Fraud Detection"]
    ORACLE["Oracle Database"]
    NOTIFY["Notification Service"]
    EMAIL["Email Server"]

    CUSTOMER --> API
    API --> PAYMENT

    PAYMENT --> FRAUD
    PAYMENT --> ORACLE

    NOTIFY --> EMAIL

    CUSTOMER -.->|No Access| ORACLE

Only approved services can reach the database.

Namespace Isolation

Namespaces should be isolated.

flowchart LR
    PAYMENTS["Payments Namespace"]
    CUSTOMERS["Customers Namespace"]
    ANALYTICS["Analytics Namespace"]

    CUSTOMERS --> PAYMENTS
    PAYMENTS -.->|Blocked| ANALYTICS

Allow Communication Between Namespaces

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy

metadata:
  name: allow-payment

spec:

  podSelector:

    matchLabels:

      app: payment

  ingress:

  - from:

    - namespaceSelector:

        matchLabels:

          team: customer

Restrict Database Access

flowchart LR
    PAYMENT["Payment Service"]
    CUSTOMER["Customer Service"]
    NOTIFY["Notification Service"]
    DB["PostgreSQL"]

    PAYMENT --> DB
    CUSTOMER -.->|Blocked| DB
    NOTIFY -.->|Blocked| DB

The database should only accept requests from Payment Service.

Secure Microservices

flowchart TD
    API["API Gateway"]

    CUSTOMER["Customer Service"]
    PAYMENT["Payment Service"]
    FRAUD["Fraud Service"]
    KAFKA["Kafka"]

    NOTIFY["Notification Service"]
    EMAIL["Email Service"]

    INVENTORY["Inventory Service"]

    API --> CUSTOMER
    API --> PAYMENT

    PAYMENT --> FRAUD
    FRAUD --> KAFKA

    NOTIFY --> EMAIL

    INVENTORY -.->|Blocked| FRAUD

Verify Network Policies

oc get networkpolicy

Example

payment-policy

database-policy

customer-policy

Describe Policy

oc describe networkpolicy payment-policy

Test Connectivity

Open a Pod.

oc rsh payment-api

Test

curl http://customer-service

If communication is denied:

Connection timed out

The Network Policy is working correctly.

Useful Commands

Create Policy

oc apply -f network-policy.yaml

List Policies

oc get networkpolicy

Describe Policy

oc describe networkpolicy payment-policy

Delete Policy

oc delete networkpolicy payment-policy

Enterprise Architecture

flowchart TD
    INTERNET["Internet"]
    WAF["Web Application Firewall"]
    ROUTER["OpenShift Router"]
    GATEWAY["API Gateway"]

    CUSTOMER["Customer Service"]
    PAYMENT["Payment Service"]
    FRAUD["Fraud Service"]

    DB[("PostgreSQL")]
    KAFKA[("Kafka")]
    NOTIFY["Notification Service"]

    POLICY["NetworkPolicy"]

    INTERNET --> WAF
    WAF --> ROUTER
    ROUTER --> GATEWAY

    GATEWAY --> CUSTOMER
    GATEWAY --> PAYMENT

    PAYMENT --> FRAUD
    PAYMENT --> DB

    FRAUD --> KAFKA
    KAFKA --> NOTIFY

    POLICY -.->|"Protects"| PAYMENT
    POLICY -.->|"Protects"| DB

Common Problems

Service Cannot Connect

Possible causes:

  • Missing Ingress rule
  • Missing Egress rule
  • Wrong Pod labels
  • Wrong namespace selector

Connection Timeout

Verify

oc get networkpolicy

Check whether traffic is intentionally blocked.

Wrong Labels

Network Policies use Pod labels.

Example

matchLabels:

  app: payment

Ensure Deployment labels match exactly.

Database Not Reachable

Verify the database Egress rule allows traffic on the correct port.

Production Best Practices

  • Adopt a Zero Trust networking model.
  • Create one Network Policy per microservice.
  • Restrict database access.
  • Allow only required ports.
  • Isolate namespaces.
  • Deny all traffic by default and explicitly allow required communication.
  • Regularly review Network Policies.
  • Monitor denied connections.

Common Mistakes

❌ Allowing all Pods to communicate.

❌ Exposing databases directly.

❌ Forgetting Egress rules.

❌ Using incorrect Pod labels.

❌ Not testing connectivity after policy changes.

Advantages

  • Improved security
  • Zero Trust networking
  • Namespace isolation
  • Reduced attack surface
  • Better compliance
  • Secure microservice communication
  • Fine-grained network control
  • Enterprise-ready security

Summary

Network Policies provide fine-grained network security for OpenShift applications.

Key takeaways:

  • Network Policies control Pod-to-Pod communication.
  • Ingress policies define who can access an application.
  • Egress policies define where an application can send traffic.
  • Namespace isolation improves multi-team security.
  • Combining RBAC, SCC, Service Accounts, and Network Policies creates a strong defense-in-depth security model.

Interview Questions

  1. What is a Network Policy?
  2. Why are Network Policies important?
  3. What is the difference between Ingress and Egress policies?
  4. How do Network Policies implement Zero Trust networking?
  5. How can you restrict database access using Network Policies?
  6. What happens if a Pod doesn't match the policy selector?
  7. How do Network Policies use Pod labels?
  8. Can Network Policies isolate namespaces?
  9. How do you verify a Network Policy is working?
  10. What are the best practices for securing microservices with Network Policies?