Microservices architecture has become the default approach for cloud-native government software — and for defense programs operating under DoD's push toward Platform One, Iron Bank, and DevSecOps Software Factories, containerized microservices are essentially table stakes.
But defense microservices have constraints that commercial microservices don't. Security requirements, ATO implications, service mesh configurations for classified network segments, and image provenance requirements all add complexity that most commercial cloud teams aren't equipped to handle out of the box.
This article covers what microservices delivery looks like as a defense program subcontract, and what prime contractors should expect from cloud engineering subs working in containerized defense environments.
How Defense Microservices Differ From Commercial
Image provenance and hardening requirements: In commercial software, teams pull base images from Docker Hub or ECR and build on them. In defense programs, base images must come from approved sources with verified provenance — Iron Bank (the DoD's hardened container registry) for most DoD software, or equivalent commercial equivalents with documented provenance.
Platform One and Iron Bank compliance covers how the DoD's approved image pipeline works. Teams that aren't sourcing images from Iron Bank on DoD programs face significant ATO challenges when auditors ask about base image hardening.
STIG requirements on container runtime: Container workloads on DoD programs must operate with STIG-compliant runtime configurations — specific AppArmor or seccomp profiles, read-only root filesystems, non-root user execution, no privileged containers. STIG compliance automation in Kubernetes describes how to enforce these at the cluster level with OPA/Gatekeeper or Kyverno policies.
Service mesh for classified network segments: Defense programs with compartmented network segments need service mesh configurations that enforce mutual TLS (mTLS) between all service-to-service communication — not just at the perimeter. Istio with strict mTLS mode is the dominant implementation on DoD programs. Every service communicates over an authenticated, encrypted channel that's audit-logged.
ATO implications of each new microservice: In a commercial environment, deploying a new microservice is a development decision. In a defense program, every new system component within the ATO boundary needs to be documented in the SSP and reviewed by the ISSO. Programs with high microservice deployment rates need a process for rapid SSP updates or a pre-approved service template approach that covers new microservices within an existing ATO boundary.
Network policy enforcement: Kubernetes network policies that explicitly allow only required service-to-service communication are required in most defense program architectures. Default-deny ingress and egress at the namespace level, with explicit allow policies for each service interaction, creates a micro-segmented architecture that limits blast radius for any compromised service.
Microservice Architecture Patterns for Defense Programs
Domain-driven service decomposition: Defense systems often start as monoliths or as inherited legacy systems being decomposed. Domain-driven design (DDD) provides a discipline for identifying microservice boundaries that map to organizational and operational seams in the system — reducing the cross-service coupling that makes defense microservice systems brittle.
API gateway pattern: All external access to the microservice mesh runs through a hardened API gateway (Kong, Envoy, AWS API Gateway with WAF, or equivalent). The gateway handles authentication, rate limiting, request validation, and audit logging — centralizing security controls that would otherwise need to be implemented in every individual service.
Event-driven communication for async workflows: Defense systems frequently need asynchronous event processing — sensor data ingestion, alert propagation, mission data updates. Event-driven microservices using Kafka or AWS Kinesis for the defense cloud decouple producers from consumers and provide a durable audit trail of all events.
Circuit breakers for resilience: Defense systems can't afford cascading failures from one degraded service. Circuit breakers at the service mesh layer or in application code prevent a single service failure from propagating to dependent services.
Kubernetes on Defense Programs
Kubernetes is the standard orchestration layer for containerized defense workloads. Kubernetes in regulated government environments covers the baseline configuration requirements in detail.
Key considerations for defense program Kubernetes:
Cluster hardening: CIS Kubernetes benchmark and DISA STIG for Kubernetes both specify cluster-level hardening configurations. These should be enforced at cluster creation through IaC and validated continuously with compliance scanning.
Namespace isolation: Production, staging, and any multi-tenant workloads run in separate Kubernetes namespaces with RBAC-enforced isolation. Defense programs with compartmented data may need separate clusters for each compartment.
Sealed Secrets or Vault integration: Kubernetes Secrets are not encrypted by default — they're base64 encoded. Defense programs must use encrypted secrets management, either via Sealed Secrets (for GitOps workflows) or direct Vault integration with the Vault Agent Sidecar Injector.
Admission control: OPA/Gatekeeper or Kyverno admission controllers enforce policy at deploy time — preventing non-compliant configurations from being deployed to production. This is the enforcement mechanism for STIG runtime requirements and image provenance requirements.
What Prime Contractors Need From a Microservices Sub
Primes on defense software programs need microservices subs who:
Understand the compliance landscape: STIG, Iron Bank, network policy, and ATO implications are first-class concerns — not afterthoughts. Subs who understand these constraints prevent expensive rework late in the development cycle.
Deliver to the program's security posture: Service configurations, network policies, and image selection need to be consistent with the program's documented architecture and ATO scope. Deviations need formal approval, not informal workarounds.
Maintain clean service boundaries and documentation: Microservices that are well-documented — clear API contracts, documented dependencies, defined SLOs — are maintainable by other teams across the program lifecycle. Undocumented microservices become maintenance liabilities.
Operate within the prime's delivery cadence: The sub's service deployments need to integrate with the prime's CI/CD pipeline, release approval processes, and government deployment gates. Independent deployment cadences that bypass program controls are a compliance problem.
Learn how Rutagon builds and delivers containerized defense software →
Frequently Asked Questions
What is Iron Bank and why is it required for DoD microservices?
Iron Bank is the Department of Defense's hardened container image registry, operated by Platform One. It provides DoD programs with STIG-hardened, CVE-scanned base images with documented provenance. Using Iron Bank images as the base for DoD containerized applications provides ATO reviewers with verified provenance and reduces the attack surface compared to commercial base images.
Does every microservice on a DoD program need its own ATO?
Not necessarily. Programs typically define an ATO boundary at the system level. New microservices within that boundary are documented as system components in the SSP rather than requiring independent ATOs. However, SSP updates are required for each new system component, and the ISSO needs to review significant architectural changes. A pre-approved service template can streamline this for programs with high deployment rates.
What is mTLS and why is it required in defense microservice environments?
Mutual TLS (mTLS) means both the client and server authenticate each other with TLS certificates. In a service mesh like Istio, mTLS is enforced for all service-to-service communication — ensuring that only authenticated, authorized services can communicate with each other, and that all inter-service traffic is encrypted. This is required for defense programs operating on networks where internal traffic must be authenticated.
Can a small engineering sub deliver production microservices on a cleared defense program?
Yes. Cleared personnel requirements apply to programs where team members need access to classified information. Many defense software programs are unclassified or handled at the Sensitive But Unclassified level where cleared personnel aren't required. For classified programs, the sub's key personnel need appropriate clearances, which can be sponsored through the prime or held independently.
What documentation does a sub need to produce for microservices on a defense program?
Typically: API contracts (OpenAPI specs), architecture diagrams showing service interactions and network flows, STIG compliance evidence, container image provenance documentation, and SSP component additions for any new services added to the system boundary. CDRLs in the subcontract specify the exact deliverable formats and submission schedule.