Military Workload Cloud Security: Hardening Kubernetes for Classified and Sensitive Defense Workloads

By Corvus Intelligence Engineering Team · About the team →

May 29, 2026 Updated: May 29, 2026 13 min read

Kubernetes has become the default orchestration platform for defense cloud workloads — from containerized C2 systems and sensor-data pipelines to AI inference services running at the tactical edge. That adoption brings a security problem that enterprise Kubernetes hardening guides do not address: the threat model for a military workload is fundamentally different from the threat model for a commercial SaaS application. The adversary has nation-state resources, the insider threat has a security clearance, the supply chain is a legitimate attack vector, and the consequences of a container escape or data exfiltration are classified-data-loss rather than PCI fine. Standard enterprise hardening is necessary but not sufficient.

This guide covers the full stack of military workload cloud security for Kubernetes: the defense-specific threat model, pod isolation, network segmentation, secrets management, RBAC hardening, image supply chain integrity, runtime anomaly detection, and continuous compliance automation. It is written for platform engineers and security architects standing up or hardening Kubernetes for defense use — not for procurement teams writing requirements.

1. defense Kubernetes threat model

Before picking controls, it is worth being explicit about what you are defending against. Four threat categories dominate military Kubernetes environments, and they require different control layers.

Hostile insider with legitimate access. In a defense environment, insiders hold clearances — which means they have already passed a background investigation and hold some level of authorized access. The insider threat is not someone who was accidentally given too much access; it is someone who deliberately abuses authorized access, potentially under coercion or ideological motivation. Controls must assume that an attacker can authenticate legitimately and must rely on least-privilege, behavioral monitoring, and tamper-evident audit trails rather than on perimeter authentication alone.

Supply chain compromise. Nation-state adversaries have demonstrated willingness to compromise upstream software supply chains — build systems, open-source packages, container base images, and CI/CD pipelines. A container image that passes all functional tests can carry a backdoor introduced at the build layer. Controls must treat every container image as potentially compromised until a verified cryptographic attestation proves otherwise, and must assume that known-good images can be replaced at any point in the supply chain.

Network-based lateral movement. Kubernetes clusters, by default, allow unrestricted pod-to-pod communication within the cluster network. An attacker who achieves code execution inside any container — through a vulnerability in an exposed service, a deserialization bug, or a compromised dependency — can immediately scan and attack every other service in the cluster. Defense clusters running multi-classification or multi-tenant workloads cannot tolerate this default. Network controls must assume compromise of at least one pod at all times.

Container escape. A container escape is a vulnerability that allows code running inside a container to break out of the container boundary and execute with host-kernel or host-root privileges. Container escapes have been demonstrated through kernel vulnerabilities (runc CVE-2019-5736, CVE-2022-0185), privileged container misconfigurations, and unsafe volume mounts. For classified workloads, a container escape is equivalent to direct access to the host — and potentially to every other workload on that node. Runtime hardening and node isolation must account for the possibility of a successful escape.

2. pod security: PodSecurityAdmission and container hardening

The first and most direct control layer is pod-level security enforcement at admission time. The deprecated PodSecurityPolicy (PSP) was replaced in Kubernetes 1.25 by the built-in PodSecurityAdmission (PSA) controller, which is now the standard mechanism.

PSA enforces one of three profiles at the namespace level: privileged (no restrictions), baseline (prevents the most dangerous configurations), and restricted (the full hardened profile). For military workloads, the restricted profile is the baseline requirement. Label every application namespace:

pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: latest
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted

The restricted profile enforces: no privileged containers, no host namespace sharing (hostPID, hostIPC, hostNetwork), no root user (runAsNonRoot: true), read-only root filesystem (readOnlyRootFilesystem: true), all capabilities dropped with only specific ones added back, and a seccomp profile of RuntimeDefault or Localhost.

Beyond PSA, all containers should drop ALL capabilities and add back only what is explicitly required. Most application containers need zero Linux capabilities. Requiring a justification for any capabilities.add entry — reviewed and approved by the security team — is a process control that keeps capability creep from silently weakening the posture over time.

3. network policies: zero-trust pod-to-pod communication

The Kubernetes network model allows any pod to reach any other pod by default. For military workloads, this default must be inverted. Every namespace requires a default-deny NetworkPolicy applied at creation time:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: mission-workload
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Calico and Cilium are the two CNI plugins suited for defense use. Calico is the more widely deployed option and implements standard Kubernetes NetworkPolicy plus its own GlobalNetworkPolicy CRD for cluster-wide rules. Cilium implements standard NetworkPolicy and additionally provides Layer 7 policy (allow only HTTP GET /api/v1/data, not all TCP on port 80), DNS-based egress policy (allow egress only to specific FQDNs rather than IP ranges), and deep visibility via eBPF without a sidecar.

For air-gapped defense clusters, egress blocking is non-negotiable. All pod egress to external networks must be denied by default, with exceptions only for specific documented flows (NTP, internal DNS, approved data-pull endpoints) approved through a change management process. Cilium's DNS-based egress policy is particularly useful here: instead of maintaining IP allowlists that drift as infrastructure changes, you allow DNS names that resolve within your controlled internal DNS.

Multi-tenant clusters — where workloads at different classification levels coexist on the same physical cluster — require network policy enforcement that is verified at the kernel level, not just at the API layer. Cilium's eBPF enforcement drops disallowed packets in the kernel network stack, before they reach the application, regardless of whether an attacker has found a way to bypass the kube-proxy layer.

4. secrets management: Vault, sealed secrets, and HSM-backed KMS

Kubernetes Secrets are base64-encoded values stored in etcd. Without envelope encryption backed by a hardware security module or cloud KMS, anyone with read access to etcd has plaintext access to every secret in the cluster. That is not an acceptable posture for a defense environment.

HashiCorp Vault is the standard secrets management solution for defense Kubernetes. The architecture for a hardened deployment:

Vault runs as a StatefulSet in a dedicated vault-system namespace, isolated by NetworkPolicy from all application namespaces. Auto-unseal uses an HSM (for on-prem clusters) or a cloud KMS with hardware-backed key material (for cloud clusters). The Vault agent injector — a mutating admission webhook — intercepts pod creation and injects a vault-agent init container and sidecar that authenticate to Vault using the pod's Kubernetes ServiceAccount token, retrieve the required secrets, write them to an in-memory tmpfs volume (never to disk), and keep them rotated for the lifetime of the pod.

The critical configuration detail: application containers must read secrets from the injected /vault/secrets/ path, not from environment variables. Environment variables are visible in /proc/<pid>/environ to any process on the same host with sufficient privileges — a container escape immediately exposes them. File-based secrets in tmpfs survive only in memory and disappear when the pod terminates.

Sealed Secrets solve the GitOps bootstrap problem: how do you store the initial Vault authentication credentials (or any static secret) in a Git repository without committing plaintext? The SealedSecret controller in the cluster holds an asymmetric key; you encrypt with the public key using kubeseal, commit the ciphertext to Git, and only the in-cluster controller can decrypt. The Git repository becomes the source of truth for all configuration including bootstrapped credentials — without exposing them. Sealed Secrets and Vault are complementary: Sealed Secrets for static bootstrap credentials and low-sensitivity config, Vault for all dynamic, high-value, and frequently-rotated secrets.

For the highest classification tiers, the KMS backing Vault's auto-unseal should be hardware-backed — a FIPS 140-2 Level 3 HSM on-prem or the cloud provider's dedicated HSM service (AWS CloudHSM, Azure Dedicated HSM). Software-backed KMS keys have the entire key lifecycle in software that could theoretically be exfiltrated; HSM-backed keys are never exported in plaintext.

5. RBAC hardening: least-privilege, namespace isolation, audit logging

Kubernetes RBAC is powerful but defaults to permissive behavior in several ways that defense clusters must explicitly close. The hardening pattern has three components.

Least-privilege service accounts. Every workload should run under a dedicated ServiceAccount — never the default service account. Token automounting should be disabled by default on all ServiceAccounts and enabled explicitly only where a workload needs to call the Kubernetes API:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sensor-processor
  namespace: mission-workload
automountServiceAccountToken: false

When a workload does need API access, grant the minimum set of verbs on the minimum set of resources, scoped to the workload's own namespace. No ClusterRoleBindings for application workloads. Cluster-scoped roles are for cluster operators only, and access to those roles should be gated by a privileged access workstation (PAW) workflow with MFA and time-limited credentials.

Namespace isolation. In multi-tenant defense clusters, namespace boundaries are a security boundary, not just an organizational convention. Enforce this with: ResourceQuotas to prevent resource exhaustion attacks across namespace boundaries, LimitRanges to prevent memory-bomb attacks from poorly configured containers, and NetworkPolicy default-deny as described above. For workloads at different classification levels, namespace isolation alone is insufficient — they should run on dedicated node pools with node affinity and taints/tolerations ensuring physical separation, or on separate clusters entirely.

API audit logging. The Kubernetes API server audit log is the most important forensic artifact in a Kubernetes cluster. Configure it with a policy that captures RequestResponse level for Secrets, ConfigMaps, Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings — every read and write of sensitive objects is logged with full request and response bodies. Audit logs must be shipped in real time to an external, append-only log store (a SIEM or a dedicated logging cluster with immutable storage) that is outside the blast radius of a compromised application workload. Operators of the cluster must not be able to modify or delete audit logs — this is both a security control and a compliance requirement under most defense security frameworks.

6. image supply chain: Cosign signing, admission webhooks, private registry

Container image supply chain security addresses the threat of compromised images entering the cluster — whether through a compromised CI/CD pipeline, a malicious upstream base image, or direct registry manipulation. The defense posture is: every image must carry a verifiable cryptographic signature from a key held in controlled hardware, and unsigned images must be rejected at admission.

Cosign (part of the Sigstore project) attaches a signature to an OCI image manifest in the registry. The signing process in CI:

cosign sign --key awskms:///arn:aws:kms:region:account:key/key-id \
  registry.internal.mil/sensor-processor:sha256-abc123

The signing key lives in KMS (or HSM), never on the CI runner. The CI pipeline's ServiceAccount has permission to call KMS for signing but cannot export the key material. Any image that was not built and signed by the controlled CI pipeline fails the signature check.

Kyverno is the recommended admission controller for defense Kubernetes (simpler policy language than OPA Gatekeeper for image verification use cases). A ClusterPolicy that enforces signature verification:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-image-signature
    match:
      any:
      - resources:
          kinds: [Pod]
    verifyImages:
    - imageReferences: ["registry.internal.mil/*"]
      attestors:
      - entries:
        - keys:
            publicKeys: |-
              -----BEGIN PUBLIC KEY-----
              <your-cosign-public-key>
              -----END PUBLIC KEY-----

Every Pod creation is blocked unless the image in registry.internal.mil carries a valid Cosign signature. The private registry is an air-gapped or firewall-isolated internal registry — no pulls from Docker Hub, Quay, or any public registry are permitted in production namespaces. A separate "import" process, with signature verification and vulnerability scanning, is the only path from public upstream to the internal registry.

7. runtime security: Falco, eBPF monitoring, gVisor for untrusted workloads

Admission-time controls prevent known-bad configurations from entering the cluster. Runtime security catches malicious behavior after a workload is running — including behavior that was impossible to predict at admission time, such as a zero-day exploit or a logic bomb triggered by a specific condition.

Falco is the CNCF-graduated runtime security tool for Kubernetes. It attaches to the kernel via an eBPF probe or kernel module and matches the stream of syscalls against a rule set. Default rules cover the MITRE ATT&CK framework and CIS Benchmark requirements. Defense-specific custom rules to add:

Detecting any shell spawned inside a mission-workload container (execve of sh, bash, or dash inside a container). Detecting any outbound connection from a namespace where egress should be blocked (cross-validation with NetworkPolicy — the eBPF layer catches what network policy might miss in edge cases). Detecting writes to sensitive paths (/etc, /var/run/secrets, /proc/sysrq-trigger). Detecting privilege escalation attempts (setuid, setgid, capset syscalls from non-privileged contexts).

Falco alerts should be shipped to the SIEM in real time, not batched. For classified environments, the SIEM itself must be accredited at the appropriate classification level. Integration with a SOAR playbook that automatically isolates a suspect pod (by removing its NetworkPolicy allowances or cordoning the node) is the advanced pattern — see the SIEM/SOAR military integration guide for the full automation architecture.

gVisor is an application kernel sandbox from Google. It runs each container under a user-space kernel (the "Sentry") that intercepts syscalls before they reach the Linux host kernel. The container process sees a normal Linux syscall interface; the Sentry translates to a small set of host syscalls, dramatically reducing the attack surface for kernel exploits. The tradeoff is performance — gVisor adds meaningful latency to syscall-heavy workloads.

The right placement pattern for defense: use gVisor (via the runsc runtime class) for the untrusted workload tier — user-submitted analysis jobs, third-party data-processing pipelines, or any container image that cannot be fully internally verified. Use standard containerd with Falco, seccomp, and AppArmor for the trusted mission workload tier where the latency budget is tight. Enforce the runtime class distinction through a Kyverno policy that assigns runtimeClassName: gvisor to all pods in the untrusted namespace.

8. compliance automation: kube-bench, STIG checks, continuous reporting

Manual compliance audits produce point-in-time snapshots that are stale the moment the cluster changes. For defense Kubernetes, compliance must be continuous — every change to cluster configuration triggers a re-evaluation, and the current compliance posture is always visible in a dashboard.

kube-bench is the standard tool for CIS Kubernetes Benchmark checks. Run as a Kubernetes Job or CronJob, it checks API server flags, etcd configuration, kubelet settings, and RBAC posture against the CIS benchmark version appropriate for your Kubernetes release. The DISA Kubernetes STIG maps closely to the CIS benchmark with additional DoD-specific requirements around audit logging, encryption at rest, and network isolation. A mapping table between kube-bench check IDs and STIG Check IDs enables automated evidence collection for authorization packages.

The continuous compliance architecture:

kube-bench runs as a DaemonSet Job nightly (and on-demand via CI/CD pipeline hooks). Results are parsed from JSON output into a compliance database. A Grafana dashboard (or your accreditation authority's preferred reporting tool) shows current pass/fail by benchmark section with trend over time. Failing checks above a severity threshold block promotion of infrastructure changes in the GitOps pipeline — a change to a Terraform module that would degrade the cluster's CIS score is rejected before it reaches production.

Beyond kube-bench, the compliance stack should include: Trivy or Grype for CVE scanning of all images in the registry (with a policy that blocks images above a CVSS threshold from being deployed), Checkov for static analysis of Kubernetes manifests and Helm charts before they enter the cluster, and Polaris for ongoing workload configuration validation against best-practice rules (similar to kube-bench but for workload manifests rather than cluster configuration).

Key insight: The most common failure mode in defense Kubernetes security is not missing a single control — it is the gap between what the admission-time policy says and what is actually running in the cluster after six months of operational changes. Continuous compliance automation closes that gap. A cluster that passed a hardening review at initial deployment but drifted over time is more dangerous than a cluster that never claimed compliance, because the false confidence it creates delays response when something goes wrong. Treat compliance posture as a real-time metric, not an annual audit artifact. For the surrounding security framework, see the complete defense cybersecurity guide.

Military workload cloud security on Kubernetes is not a single configuration decision — it is a layered set of controls that each address a distinct threat vector and must be maintained continuously as the cluster and its workloads evolve. Pod security prevents the most dangerous container configurations from being scheduled. Network policy contains lateral movement if a container is compromised. Vault and sealed secrets ensure credentials are never in plaintext at rest. RBAC hardening limits the blast radius of a compromised service account. Image signing ensures only verified code runs. Falco detects behavior that bypassed every admission control. And continuous compliance scanning ensures the cluster has not drifted from the hardened baseline. Each layer assumes the one before it has failed — and that assumption is correct for a defense-grade threat model.

Discuss Your Project

We design and build hardened Kubernetes platforms for defense — from pod security and secrets management to Falco-SIEM integration and continuous STIG compliance automation.

Secure Cloud Services → Book a Briefing

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

Frequently Asked Questions

What is military workload cloud security?

Military workload cloud security refers to the set of architectural, operational, and compliance controls applied to Kubernetes clusters or cloud infrastructure that host classified or sensitive defense data. It goes beyond standard enterprise hardening to address threat models that include hostile insiders with clearances, nation-state supply chain attacks, container escape attempts, and strict air-gap or network segmentation requirements imposed by classification policy.

What is PodSecurityAdmission and why does it matter for defense?

PodSecurityAdmission (PSA) is the built-in Kubernetes admission controller that replaced the deprecated PodSecurityPolicy. It enforces one of three profiles — privileged, baseline, or restricted — at the namespace level. The restricted profile prevents containers from running as root, sharing host namespaces, using privileged mode, writing to the root filesystem, or holding dangerous Linux capabilities. For defense workloads, enforcing restricted across all application namespaces is a baseline requirement, not an optional hardening step.

How do you implement zero-trust networking inside a Kubernetes cluster?

Zero-trust pod networking requires a CNI plugin that supports NetworkPolicy — Calico and Cilium are the standard choices for defense environments. The pattern is: apply a default-deny ingress and egress policy to every namespace at creation time, then add explicit allow rules only for required flows. Cilium's eBPF-based policy engine also enables Layer 7 visibility so you can allow only specific HTTP methods or DNS queries, not entire TCP connections. Egress blocking is essential for air-gapped clusters.

What is the difference between Kubernetes Secrets and HashiCorp Vault for defense use?

Kubernetes Secrets are base64-encoded and stored in etcd. Without envelope encryption backed by an HSM or cloud KMS, they are effectively plaintext to anyone with etcd access. HashiCorp Vault provides dynamic secrets, HSM-backed unsealing, fine-grained ACL policies, a full audit log of every secret access, and automatic secret rotation. For classified workloads, Vault with vault-agent sidecar injection is the required pattern.

What is Cosign image signing and how does it protect defense Kubernetes clusters?

Cosign attaches a cryptographic signature to a container image in the OCI registry. An admission webhook — Kyverno or OPA Gatekeeper — verifies that signature against your organization's public key before allowing a pod to schedule. This closes the supply chain attack vector: even if an attacker compromises your CI pipeline and pushes a malicious image, it will be rejected at admission because it lacks a valid signature from the controlled signing key. The signing key should be stored in an HSM or KMS.

What does Falco do in a military Kubernetes environment?

Falco monitors kernel syscalls in real time using an eBPF or kernel module driver, matching the stream of syscalls against a rule set and firing alerts for anomalous behaviors: a shell spawning inside a container, unexpected outbound network connections, writes to sensitive paths, or privilege escalation attempts. In military Kubernetes environments, Falco provides the host-based intrusion detection layer that catches container escapes and insider-threat behaviors that network controls cannot see.

What is kube-bench and how does it relate to DISA STIG compliance?

kube-bench runs the CIS Kubernetes Benchmark checks against a live cluster — checking API server flags, etcd configuration, kubelet settings, RBAC posture, and network policies. The DISA Kubernetes STIG maps closely to the CIS Benchmark with additional DoD-specific requirements. Running kube-bench as a scheduled job and mapping results to STIG check IDs gives automated, continuous compliance evidence rather than a point-in-time audit snapshot. Failing checks block promotion in CI/CD pipelines.

When should gVisor be used for defense workloads?

gVisor interposes a user-space kernel between the container process and the Linux host kernel, dramatically reducing the kernel attack surface available to a container escape. For defense, gVisor is appropriate for untrusted workloads — user-uploaded analysis code, third-party data-processing containers, or any workload where container image provenance cannot be fully verified. The tradeoff is performance overhead that makes it unsuitable for latency-sensitive mission workloads. Use gVisor for the untrusted tier; use standard containers with Falco and seccomp for trusted mission workloads.

What are sealed secrets and why are they used in defense GitOps?

Sealed Secrets is a Kubernetes operator that lets you store encrypted secret manifests in Git. The SealedSecret controller holds an asymmetric key pair; you encrypt a Kubernetes Secret with the public key using kubeseal, and the resulting SealedSecret manifest is safe to commit. Only the in-cluster controller can decrypt it. For defense GitOps workflows where Git is the source of truth for all configuration, Sealed Secrets enables storing credentials in the repo without exposing plaintext. It complements Vault: use Sealed Secrets for bootstrap credentials and static config, Vault for dynamic and high-value secrets.

How do you handle audit logging for a classified Kubernetes cluster?

Kubernetes audit logging must be configured at the API server level with a policy file that captures at least Metadata level for all requests and RequestResponse level for secrets, configmaps, and RBAC changes. Audit logs should be shipped in real time to an immutable, append-only log store — a SIEM or a dedicated logging cluster with write-once storage — outside the blast radius of a compromised workload cluster. For classified environments, log retention, tamper-evidence requirements, and access controls are defined by the classification authority's security operating procedures.