What is microsegmentation in zero-trust network architecture?

Microsegmentation is the practice of dividing a network into small, isolated segments at the workload or application layer — not just at the VLAN or subnet level — and enforcing granular access policies between those segments. In a zero-trust architecture, every segment boundary is a trust boundary: traffic crossing it must be authenticated, authorized, and inspected regardless of whether it originates inside or outside the traditional perimeter. For defense networks, microsegmentation limits the blast radius of a compromise by preventing an attacker who gains access to one workload from freely traversing to others.

What is east-west traffic and why is it the primary attack surface?

East-west traffic is network communication between workloads within the same data center, cloud environment, or enclave — as opposed to north-south traffic, which enters or exits the environment across a defined perimeter. In a traditional perimeter-based security model, east-west traffic is largely uninspected: once inside the perimeter, a workload can generally reach other workloads freely. This is the primary attack surface for lateral movement after initial compromise. An attacker who obtains credentials for a low-privilege service can pivot to higher-value targets if east-west controls are absent. Zero-trust microsegmentation addresses this by enforcing policy on every east-west flow, not just perimeter ingress.

How is workload identity established in a microsegmented defense environment?

Workload identity in a zero-trust microsegmented environment is typically established using short-lived cryptographic credentials bound to a specific workload. In Kubernetes-based deployments, SPIFFE (Secure Production Identity Framework For Everyone) and its implementation SPIRE issue X.509 SVIDs (SPIFFE Verifiable Identity Documents) to each pod or service based on its Kubernetes service account. These SVIDs carry a URI SAN of the form spiffe://trust-domain/ns/namespace/sa/service-account, which policy engines use to authorize traffic. The short lifetime of SVIDs (typically 1 hour) bounds the window of exposure if a credential is compromised.

What enforcement mechanisms are used for east-west policy in Kubernetes?

Kubernetes-native NetworkPolicy objects provide L3/L4 enforcement at the pod selector level but lack L7 visibility and cryptographic workload identity. Production-grade east-west enforcement in defense environments typically layers three controls: Kubernetes NetworkPolicy for base IP-level allow/deny; a service mesh (such as Istio or Linkerd in FIPS mode) that enforces mTLS between services using workload identities and applies L7 authorization policy; and an eBPF-based enforcement plane (such as Cilium) that operates below the kernel network stack for kernel-level enforcement that cannot be bypassed by compromised container runtimes.

How does microsegmentation policy interact with classification enclaves?

In a multi-enclave defense environment, microsegmentation policy maps directly to classification boundaries. Each classification level — unclassified, CUI, SECRET — maps to a separate trust domain. Workloads within the same enclave are microsegmented by function and role: a database service is not reachable from an API gateway in the same enclave unless an explicit allow rule exists. Cross-enclave communication is prohibited at the microsegmentation layer and handled exclusively by an accredited cross-domain solution that performs content inspection, re-classification labeling, and one-way or bidirectional transfer according to the program's data transfer policy.

Zero-trust microsegmentation for defense networks: policy and enforcement

Perimeter security was built around a simple assumption: traffic originating inside the boundary could be trusted. In a defense network that assumption was never fully valid, and in a modern hybrid cloud or multi-enclave environment it is architecturally untenable. The attacker who has compromised a single endpoint or stolen service credentials does not stop at the perimeter – they move laterally, escalating from low-value workloads to high-value targets. Microsegmentation under a zero-trust architecture is the control that limits lateral movement to the single compromised workload rather than the entire enclave. This article examines how to design, enforce, and maintain identity-based microsegmentation policy in defense networks, with specific attention to Kubernetes-hosted workloads, workload identity provisioning, and east-west enforcement mechanisms.

Why perimeter-only controls fail in defense environments

Traditional network security in defense environments relies on physical and logical segmentation at large granularity: separate networks for different classification levels, VLAN boundaries between functional areas, and firewall rules at the perimeter of each segment. This model has two structural weaknesses that microsegmentation is designed to address.

Flat east-west traffic. Within a VLAN or subnet, workloads typically communicate without restriction. A compromised application server can reach the database, the authentication service, the key management system, and every other service on the same subnet – not because there is a policy allowing it, but because there is no policy denying it. The attacker's lateral movement cost inside a flat segment is low.

Credential-based compromise crosses perimeters. Perimeter firewalls inspect packet headers, not workload identity. A stolen service account token or certificate that was valid for communication between two services is equally valid for communication from the attacker's process running as that service. The firewall permits the traffic because it comes from the correct source IP. Microsegmentation with cryptographic workload identity addresses this: the policy principal is not an IP address but a cryptographically attested workload identity that the attacker cannot impersonate without access to the private key material – which is ephemeral and workload-bound.

Microsegmentation architecture: trust domains and policy boundaries

A microsegmentation design for a defense network begins with mapping communication flows and grouping workloads into trust domains. A trust domain is a set of workloads that share a common authorization boundary and communicate freely within the group, but require explicit policy to communicate outside it. In a defense context, the natural trust domain boundaries align with both classification level and functional role.

For a typical defense application hosted on a classified Kubernetes cluster, trust domains might be:

Classification-level domains. Each classification enclave – unclassified, CUI, SECRET – is a separate trust domain. No east-west communication crosses classification boundaries within the microsegmentation plane. Cross-domain communication is routed exclusively through an accredited cross-domain solution that performs content inspection and re-labeling.

Functional role domains within a classification level. Within the SECRET enclave, further segmentation by function: ingestion services (accepting data from external sensors), processing services (analytics and enrichment), storage services (databases and object stores), command-plane services (orchestration and scheduling), and audit services (immutable logging). Each functional domain can only receive traffic from the specific peer domains whose communication flows are documented and policy-approved.

The communication flow map that results from this exercise – every source domain, destination domain, port, and protocol that is business-justified – becomes the authoritative input to policy authoring. Any flow not on the map is denied by default.

Workload identity: SPIFFE/SPIRE in Kubernetes environments

Identity-based microsegmentation requires that every workload possess a verifiable identity that the policy enforcement plane can authenticate. IP-address-based identity is insufficient in dynamic container environments where pods are ephemeral and IPs are recycled. The SPIFFE (Secure Production Identity Framework For Everyone) standard defines a portable, cryptographic workload identity model that is independent of the underlying infrastructure.

SPIFFE identity is expressed as a URI: spiffe://trust-domain/path. In a Kubernetes deployment using SPIRE (the reference SPIFFE implementation), each pod receives an X.509 SVID (SPIFFE Verifiable Identity Document) – a short-lived certificate containing its SPIFFE ID as a Subject Alternative Name. The trust domain corresponds to the Kubernetes cluster or federation boundary. The path encodes the Kubernetes namespace and service account, e.g. spiffe://defense.cluster/ns/analytics/sa/enrichment-worker.

The critical property for defense deployments is the short TTL. SVIDs are issued with a lifetime of 1 hour (or less, configurable) and rotated automatically by the SPIRE agent running on each node. If a certificate is compromised, the window of exposure is bounded by the TTL. The private key never leaves the workload's memory – it is not written to disk and not accessible to other processes on the same node, even in a shared Kubernetes cluster context.

Node attestation in classified clusters

SPIRE's node attestor is the mechanism by which a new node joining the cluster proves its identity before it is allowed to issue SVIDs to workloads. In a classified Kubernetes environment, the node attestor must be chosen to match the trust model. For on-premises classified hardware, TPM-based attestation – using the node's Trusted Platform Module to prove hardware identity – is the preferred model. The SPIRE server validates the TPM endorsement key against a known-good manifest before authorizing the node to act as an SVID issuer. This means that an attacker who provisions an unauthorized node cannot obtain valid SVIDs from the SPIRE server, even if they have network access to the cluster API server.

East-west enforcement: service mesh and eBPF

Workload identity provisioning is necessary but not sufficient – the enforcement plane must actually use those identities to allow or deny traffic. In a hardened Kubernetes environment, east-west enforcement is typically layered across three complementary mechanisms.

Kubernetes NetworkPolicy: L3/L4 baseline

Kubernetes NetworkPolicy resources provide a declarative way to specify which pods can communicate, using pod label selectors and namespace selectors to identify source and destination. NetworkPolicy enforcement is handled by the CNI plugin (Container Network Interface). The key limitation of standard NetworkPolicy is that it operates at L3/L4 – it can allow or deny traffic between pod groups based on IP and port, but it cannot inspect the identity of the workload making the connection, the HTTP method being called, or the content of the request. For a defense microsegmentation model that requires cryptographic identity, NetworkPolicy is a necessary baseline but not the complete control.

Service mesh with mutual TLS: L7 identity-aware enforcement

A service mesh installed in strict mutual TLS mode adds cryptographic identity verification to every east-west connection. Each service-to-service call is authenticated at the transport layer: the client presents its SVID, the server presents its SVID, and each verifies the other against the SPIFFE trust bundle. The service mesh's authorization policy then evaluates the authenticated principal (the verified SPIFFE ID) against a policy rule before permitting the request.

For defense deployments, the service mesh must be configured with FIPS 140-2 or FIPS 140-3 validated cryptographic libraries. Both Istio and Linkerd can be compiled against BoringCrypto (FIPS-validated) or equivalent. The cipher suites negotiated for mTLS must be restricted to the approved set – TLS 1.3 with AES-256-GCM-SHA384 as the minimum for classified environments. The full list of permitted suites must be documented as part of the system's security configuration baseline.

eBPF-based enforcement: kernel-level policy

Service mesh enforcement operates at the sidecar proxy layer, which runs inside the container network namespace. A sufficiently privileged attacker who can compromise the container runtime or the pod itself may be able to bypass sidecar proxies. eBPF-based network enforcement (implemented by CNI plugins such as Cilium) operates below the container runtime, at the Linux kernel's network stack. eBPF programs attached to kernel hooks evaluate network policy before packets are delivered to any userspace process – including the sidecar proxy. A workload that bypasses its sidecar proxy still cannot reach unauthorized destinations because the eBPF enforcement layer denies the packet at the kernel level.

The combination of NetworkPolicy + service mesh mTLS + eBPF enforcement creates a defense-in-depth microsegmentation stack where each layer independently enforces policy. A failure in any single layer does not result in unrestricted lateral movement.

Key insight: The most common microsegmentation failure in defense Kubernetes deployments is not a policy gap – it is a policy visibility gap. Teams author deny-all baseline policies and then add exceptions over time without removing obsolete rules. The result is a policy set that no longer reflects the actual application architecture. Continuous automated comparison of observed traffic flows (via service mesh telemetry) against the policy-approved flow map is the only reliable mechanism for detecting policy drift before it is exploited.

Policy lifecycle: authoring, testing, and maintaining microsegmentation rules

Microsegmentation policy is not a one-time configuration. Defense applications evolve, workloads are added and removed, and communication patterns change as features are developed. A microsegmentation model that is correct at initial deployment degrades over time if it is not actively maintained.

Policy-as-code. Microsegmentation policy should be version-controlled alongside application code. Every NetworkPolicy, AuthorizationPolicy, and CiliumNetworkPolicy resource should live in the application's deployment repository. Changes to policy follow the same review and approval process as code changes – including security review for any rule that expands an allow boundary. This prevents ad-hoc firewall exceptions from accumulating outside of version control.

Shadow mode testing. Before applying a new or modified policy in enforcement mode, test it in shadow (log-only) mode. The service mesh and eBPF enforcement plane can both operate in an audit mode where policy violations are logged but not blocked. Running in shadow mode for a defined period (typically one to two weeks in a staging environment mirroring production traffic patterns) surfaces undocumented flows that the policy would block before they cause production outages. Undocumented flows discovered in shadow testing must be reviewed – legitimate flows trigger policy additions, while illegitimate flows are evidence of an existing security issue.

Automated policy drift detection. Service mesh flow telemetry (Istio's Hubble, Linkerd's Viz) provides a real-time view of all east-west traffic. Automated tooling that compares observed traffic against the approved flow map and alerts on deviations is a standard operational requirement for a defense microsegmentation deployment. New flows that appear without a corresponding policy update are immediate alert candidates – either the application changed without updating its policy documentation, or an unauthorized actor is generating unexpected traffic.

Microsegmentation in multi-enclave and air-gapped environments

Defense networks frequently span multiple enclaves at different classification levels, some of which are fully air-gapped from external networks. Microsegmentation policy must be coherent across all enclaves even when there is no shared management plane.

In an air-gapped classified cluster, the SPIRE server must operate entirely on-premises. The PKI root that anchors SVID trust cannot rely on any external certificate authority. The SPIRE server's root CA and intermediate CAs are generated and managed on air-gapped HSMs (Hardware Security Modules) within the classified environment. Certificate revocation lists and OCSP services must similarly operate within the air gap – network calls to external infrastructure for PKI operations are not permitted in classified network architectures.

Cross-enclave microsegmentation coordination – ensuring that a policy allowing a flow from the CUI enclave to the unclassified enclave is mirrored in both enclaves' policy sets – is a manual and auditable process in most programs. The cross-domain solution that mediates cross-enclave traffic is the authoritative source of what flows are permitted across the boundary; microsegmentation policies on both sides must be consistent with the CDS configuration and reviewed as a unit during policy change control.

Enforce zero-trust policy across your defense network

Corvus Quantum provides post-quantum encrypted communications with built-in identity-based microsegmentation enforcement – purpose-built for classified and sensitive defense networks where east-west lateral movement is not an acceptable risk.

Explore Corvus Quantum → Book a Briefing

This analysis was prepared by Corvus Intelligence engineers who build mission-critical secure infrastructure for defense and government organizations. Learn about our team →