Policy Example 4 - Namespace-isolation Policy

Introduction

Welcome to this lesson in the Hierarchical Policy Model for Microsegmentation in Kubernetes.

In this session, we focus on Namespace Isolation Policies—policies that define perimeters around namespaces to control traffic entering or leaving them, while allowing trusted communication within.

What Is a Namespace Isolation Policy?

Namespace isolation policies:

  • Trust all workloads within a namespace to freely communicate

  • Explicitly define what traffic is allowed into or out of the namespace

  • Help create logical security zones without restricting internal service-to-service communication

Where It Fits in the Model

These policies are defined in the namespace-isolation tier, positioned after:

  1. security tier (high-level guardrails),

  2. platform tier (infrastructure policy enforcement).

Each namespace typically receives its own isolation policy for maximum control and visibility.

Example Policy: Namespace Isolation for yaobank

The yaobank namespace contains:

  • customer

  • summary

  • database workloads

Policy Overview:

  • Type: NetworkPolicy

  • Tier: namespace-isolation

  • Scope: Entire yaobank namespace

  • Selector: None (applies to all workloads in the namespace)

Key Rules:

✅ You can use selectors, ports, and namespace constraints to surgically target traffic.

Granular Control Within the Namespace

Though this example trusts all internal flows, you can:

  • Specify allowed service-to-service communication inside the namespace

  • Deny or restrict access to sensitive workloads like database from others like customer

This adds a layer of fine-grained segmentation for regulated or sensitive environments.

Policy Deployment

Step 1: Locate Namespace Policies

/policies/namespace-isolation/yaobank-isolation.yaml
/policies/namespace-isolation/bookinfo-isolation.yaml

Step 2: Apply the Policies

kubectl apply -f policies/namespace-isolation/

Step 3: Verify in Calico Cloud

  • Go to the Policy Board

  • Confirm both policies appear in the namespace-isolation tier

  • Validate policy scope, ingress/egress rules, and matched endpoints

Real-Time Validation

Using Flow Logs:

  • Generate traffic (e.g., via curl from public to workloads)

  • View matching flows under each policy

  • Verify source/destination, ports, and reporter

    • Ingress rules: reported by destination

    • Egress rules: reported by source

Using Service Graph:

  • Internal namespace flows: shown in maroon

  • Cross-namespace flows: shown in blue

  • Click arrows to view:

    • Which tier and policy allowed the flow

    • Which specific rule matched (e.g., ruleIndex: 0 = first rule)

Advanced Insights

  • Use detailed flow logs to track:

    • Rule evaluation order

    • Source and destination policies

    • Port and protocol visibility

  • Combine namespace isolation with default deny posture for full protection

  • Use flow logs to detect and troubleshoot gaps before enforcing denies

Summary

Namespace isolation policies:

  • Define a perimeter of trust within each namespace

  • Allow internal workloads to communicate freely (unless restricted)

  • Explicitly authorize external ingress and egress

  • Help standardize segmentation without overcomplicating application logic

What’s Next

In the next video, we’ll define policies for the Workload Isolation Tier to apply surgical controls within a namespace—especially useful for sensitive or exposed services.

Thanks for watching, and see you in the next lesson!