luvv to help

Menu

Topic 3 of 8

Network Segmentation And Zero Trust Basics

Learn Network Segmentation And Zero Trust Basics for free with explanations, exercises, and a quick test (for Platform Engineer).

Published: January 23, 2026 | Updated: January 23, 2026

Table of Contents

Why this matters

As a Platform Engineer, you’ll be asked to reduce blast radius, stop lateral movement, and enable safe connectivity between services and users. Network segmentation and Zero Trust are the foundation. You will:

  • Design VPC/subnet layouts and firewall rules that minimize exposure.
  • Enforce pod-to-pod policies in Kubernetes using NetworkPolicy.
  • Enable identity-aware access for admins and CI/CD without opening broad network paths.
  • Pass security reviews by demonstrating default-deny and least-privilege flows.

Progress note: The quick test is available to everyone; sign in to save your progress.

Concept explained simply

Network segmentation means dividing your network into smaller zones and controlling which zones can talk to each other. If something is compromised, the damage stays local.

Zero Trust means “never trust, always verify.” Instead of trusting a whole network, every request is verified using identity, context (device, location), and policy, then given the minimum access needed.

Mental model

Imagine an office building:

  • Floors: different network segments (public, app, data).
  • Doors with badges: firewalls and policies—only specific people (services) can enter.
  • Security guard checks ID every time: service identity and authentication, not just location.

Core principles

  • Default deny everywhere; explicitly allow only needed flows.
  • Least privilege for ports, protocols, directions, identities.
  • Verify explicitly: identity (user/service), device posture, and context.
  • Assume breach: design so a compromise stays contained.
  • Segment by sensitivity: public, app, data, admin; then microsegment inside.
  • Encrypt in transit (TLS/mTLS) and log decisions for audit.

Key building blocks

  • VPC/Subnets or VLANs: logical network boundaries and IP ranges.
  • Routing: what can reach what; keep it minimal.
  • Firewalls: stateful rules; in clouds, Security Groups are stateful; NACLs are stateless, subnet-level.
  • Kubernetes NetworkPolicy: controls pod ingress/egress (requires a CNI plugin that enforces it).
  • Identity-aware access: SSO, short-lived credentials, device checks, and proxies/gateways.
  • Service identity and mTLS: mutual TLS ensures both caller and callee are authenticated.
Tip: Picking segmentation granularity

Start coarse (public/app/data) for quick wins, then microsegment high-risk paths (e.g., only payments API can talk to DB on 5432). Monitor logs to refine over time.

Worked examples

1) Three-tier web app in a cloud VPC

  • Segments: Public subnet (Load Balancer), Private-App subnet (API), Private-Data subnet (DB).
  • Rules (default deny otherwise):
Allow: Internet -> LB : 443
Allow: LB -> API : 443 (security group ref)
Allow: API -> DB : 5432 (security group ref)
Deny: Internet -> API/DB (no rule)
Deny: API -> Internet, except updates via egress allowlist
Why this works

The LB is the only entry. API can’t be called directly from the Internet. DB is only reachable by the API on a single port. Egress is constrained to reduce data exfiltration.

2) Kubernetes microsegmentation with NetworkPolicy

Goal: Allow only pods labeled app=payments-api to talk to app=payments-db on 5432 in namespace payments.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-ingress
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payments-db
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: payments-api
      ports:
        - protocol: TCP
          port: 5432
Don’t forget default deny

Add a separate policy selecting all pods with empty rules to drop other ingress, or use your CNI’s default deny setting. Without it, traffic not matched by any policy may still be allowed.

3) Zero Trust admin access

  • Replace public SSH/RDP with an identity-aware gateway.
  • Require SSO + MFA + device posture for admins.
  • Grant short-lived access only to the target host’s management port.
Outcome

Admins don’t live on flat VPNs. Each session is verified, logged, time-bound, and scoped to the minimal destination.

Step-by-step: Start segmenting safely

  1. List your assets by sensitivity: public, app, data, admin.
  2. Map actual traffic: who talks to whom, on which ports.
  3. Define minimal allow rules for only required flows.
  4. Set default deny for all else (ingress and egress).
  5. Introduce identity checks: SSO for users, mTLS or service accounts for services.
  6. Monitor logs; tighten or remove unused rules.
Safe rollout tip

Use a “log-only” or audit mode where available, then enforce. Start with less critical environments, replicate to prod once stable.

Exercises

Do these to cement the ideas. Your answers are checked manually against the expected outcomes.

  • Exercise 1: Design a minimal rule set for a 3-tier service (see Exercises below).
  • Exercise 2: Write a Kubernetes NetworkPolicy to enforce DB isolation.

Self-check checklist

  • All flows are explicitly required for app function.
  • Rules specify ports, directions, and identities (where possible).
  • Default deny is in place for everything else.
  • Sensitive components (DB, secrets) have the fewest inbound paths.

Common mistakes and how to self-check

  • Allowing broad CIDRs like 0.0.0.0/0 for internal services. Self-check: Do any private services accept traffic from the Internet?
  • Forgetting egress rules. Self-check: Can workloads exfiltrate data to arbitrary IPs? Restrict or proxy egress.
  • Relying only on network location. Self-check: Are you verifying identity (mTLS, tokens) beyond IP?
  • No default deny. Self-check: If you remove your allow rules, does anything still work that shouldn’t?
  • Skipping observability. Self-check: Do you have logs/metrics for allowed/denied flows to refine policy?

Practical projects

  • Create a small VPC with three subnets (public/app/data). Implement stateful rules and prove that only the LB can reach the API, and only the API can reach the DB.
  • Deploy a sample app to Kubernetes and enforce a default deny with targeted NetworkPolicies. Show break/fix by toggling labels/ports.
  • Set up an identity-aware tunnel for SSH to a single host using SSO and device checks. Measure how many open ports you can remove.

Who this is for

  • Platform Engineers and SREs securing services and infrastructure.
  • Backend Engineers integrating services that must communicate safely.

Prerequisites

  • Basic networking (TCP/IP, CIDR, ports).
  • Familiarity with cloud networking or Kubernetes basics.
  • Comfort with YAML and CLI tools.

Learning path

  1. Learn segmentation concepts and default-deny.
  2. Apply to cloud constructs (VPC, subnets, security groups).
  3. Apply to Kubernetes (NetworkPolicy) and service identity (mTLS).
  4. Introduce identity-aware access for humans and CI/CD.
  5. Continuously monitor and refine; automate as code.

Next steps

  • Convert manual rules into reusable templates (IaC).
  • Add continuous tests: ensure forbidden paths remain blocked.
  • Extend Zero Trust to data layer (access brokering, short-lived credentials).

Mini challenge

You have a new internal admin UI that should be accessible only to on-call engineers using managed devices. Draft a one-paragraph policy describing:

  • Where the service lives (segment).
  • How identity is verified (SSO + MFA + device posture).
  • Which ports are allowed and from where.
  • How access is logged and time-limited.
Example answer

Place the admin UI in a private app segment; expose via an identity-aware proxy. Require SSO with MFA and compliant device checks. Allow only HTTPS 443 from the proxy to the service; deny direct Internet access. Grant on-call role 8-hour session tokens. Log all decisions and requests.

Practice Exercises

2 exercises to complete

Instructions

Given a web app with components: lb (public), api (private), db (private). Requirements:

  • Users reach the app via HTTPS only.
  • API serves TLS on 443, terminates mTLS from LB.
  • DB listens on 5432; only API may reach it.
  • All other traffic should be denied. Egress should be restricted to necessary updates at updates.example.com:443.

Produce a concise allowlist of rules (source -> destination : port/protocol) and indicate default deny elsewhere.

Expected Output
A small set of explicit allow rules: Internet->lb:443, lb->api:443, api->db:5432, api->updates.example.com:443 (egress); default deny for all other directions.

Network Segmentation And Zero Trust Basics — Quick Test

Test your knowledge with 8 questions. Pass with 70% or higher.

8 questions70% to pass
Secrets Rotation And Vault ConceptsSupply Chain Security Basics

Have questions about Network Segmentation And Zero Trust Basics?

AI Assistant

Ask questions about this tool