Kubernetes for defense workloads: orchestrating classified containerized applications

Container orchestration has become the dominant deployment pattern for modern defense software, yet the operational security requirements of classified environments impose constraints that commodity Kubernetes configurations do not address by default. A standard kubeadm-bootstrapped cluster exposes unauthenticated kubelet APIs, stores Secrets in plaintext in etcd, applies no network policies between pods, and generates audit logs that are neither forwarded nor protected from tampering. Each of these defaults is a finding in any serious security review. This article covers what it takes to run Kubernetes correctly in a classified environment: from node hardening against CIS and STIG baselines through HSM-backed secrets management, network microsegmentation, audit log architecture, image supply chain controls, and the documentation path to an Authority to Operate.

Why container orchestration matters for modern defense software deployment

Defense software has historically been deployed as monolithic applications on dedicated physical servers, with each system upgrade requiring manual coordination across multiple security domains and extensive retesting before any change reached an operational environment. Container orchestration inverts this model: applications are packaged as immutable images, infrastructure is declared as code, and the orchestrator manages scheduling, health checking, and rolling updates across a fleet of nodes. For programs that need to push capability updates to operators in weeks rather than years, this shift is not optional.

Kubernetes brings additional benefits that are specifically relevant to classified workloads. Namespace-level resource isolation allows multiple applications at the same classification level to share node infrastructure without interfering with each other's CPU, memory, or network resources. Resource quotas prevent a misbehaving workload from consuming all cluster capacity. Pod disruption budgets enforce availability constraints during maintenance windows. These controls map directly to the reliability and isolation requirements that authorizing officials expect to see documented in a System Security Plan.

The challenge is that the Kubernetes project is designed for internet-facing commercial cloud environments, and its default configuration reflects that heritage. Defense programs adopting Kubernetes must treat the default configuration as a starting point for hardening, not an acceptable baseline. The gap between a default cluster and an accreditation-ready cluster is substantial, but it is well-documented by DISA and the Center for Internet Security, and it is closeable with deliberate configuration work.

Node hardening: CIS benchmarks and STIG compliance for Kubernetes worker nodes

Node hardening begins at the operating system layer before a single Kubernetes component is installed. Worker nodes should be built from a STIG-hardened or CIS Level 2 base image -- Red Hat Enterprise Linux CoreOS (RHCOS) for OpenShift-based clusters, or a hardened Ubuntu or Rocky Linux build for upstream Kubernetes. The base OS configuration covers filesystem partitioning (separate /tmp, /var, /var/log mounts), kernel parameter hardening (disabling IP forwarding except where required by the CNI, enabling syncookies, disabling IP source routing), mandatory access control (SELinux enforcing mode or AppArmor profiles), and removal of unnecessary packages and services.

At the Kubernetes layer, the DISA STIG for Kubernetes and the CIS Kubernetes Benchmark Level 2 converge on a core set of kubelet configuration requirements. The kubelet read-only port must be disabled (--read-only-port=0). Anonymous authentication must be disabled (--anonymous-auth=false). The authorization mode must be set to Webhook, delegating all authorization decisions to the API server's RBAC engine rather than trusting node-local decisions. Certificate rotation must be enabled so that kubelet client certificates are renewed automatically before expiry. The container runtime -- containerd or CRI-O -- must be configured with a default seccomp profile (RuntimeDefault) applied to all pods unless they explicitly require a more permissive or custom profile.

Running kube-bench, the open-source CIS benchmark auditor, against a configured cluster produces a structured compliance report in XCCDF format. This report is a required attachment in most accreditation packages. Category I (high-severity) findings must be remediated before submission; Category II findings should be remediated or documented with compensating controls. Automated remediation playbooks -- Ansible or similar -- that apply the benchmark controls reproducibly across all nodes are strongly preferred over manual configuration, both because they reduce configuration drift and because they produce auditable change records.

Network policy enforcement: microsegmentation between classified workloads

By default, all pods in a Kubernetes cluster can communicate with all other pods, regardless of namespace. This flat network model is appropriate for development environments but unacceptable for classified workloads, where the principle of least-privilege access must apply to network traffic just as it does to RBAC permissions. Enforcing network segmentation requires two things: a CNI plugin that implements the Kubernetes NetworkPolicy specification, and a set of NetworkPolicy objects that define the allowed communication paths.

The baseline hardening pattern is a default-deny-all policy applied to every namespace at cluster bootstrap. This policy denies all ingress and egress traffic unless an explicit allow rule permits it. Explicit allow rules are then added for each required traffic path: DNS resolution (TCP and UDP port 53 to CoreDNS in kube-system), health check traffic from the kubelet to application containers, and application-specific service-to-service communication. Every allow rule should be scoped as narrowly as possible -- by pod label selector, namespace label selector, and port -- rather than using broad CIDR ranges that will pass an auditor's review but fail to actually constrain lateral movement.

For workloads operating at different classification levels that must coexist on shared infrastructure, label-based NetworkPolicy alone is insufficient. The CNI plugin enforces policies in the Linux kernel's netfilter layer, and a sufficiently privileged compromised container can bypass netfilter. Defense programs hosting workloads at multiple sensitivity levels on a single cluster should place each sensitivity tier in a dedicated node pool with dedicated network interfaces or VLANs, and enforce cross-tier traffic controls at the hardware or hypervisor layer. Defense cloud interconnect architecture provides the physical and logical separation that policy-only controls cannot guarantee on shared kernel infrastructure.

Secrets management: integrating Kubernetes with HSM-backed key stores

Kubernetes Secrets are, by default, stored in etcd as base64-encoded values with no encryption. Any user or process with read access to etcd -- or with sufficient RBAC permissions to call kubectl get secret -- can retrieve the plaintext value. For classified environments, this is not a configuration gap; it is a fundamental architectural problem that must be solved before any sensitive data is stored in the cluster. The solution is etcd encryption at rest using a KMS provider that delegates key management to an HSM-backed key store.

The kube-apiserver EncryptionConfiguration resource specifies a list of encryption providers for each resource type. For the kms provider, the configuration points to a Unix socket where a KMS plugin process is listening. The plugin translates the Kubernetes KMS gRPC protocol into calls to the HSM or key management service -- typically via PKCS#11 for a network-attached HSM, or via the key management API of a defense-grade cloud KMS. When the API server writes a Secret to etcd, it calls the KMS plugin to encrypt the data encryption key (DEK) under the HSM-held key encryption key (KEK). Only the wrapped DEK is stored in etcd alongside the ciphertext. Decryption requires a round-trip to the HSM. The HSM must be FIPS 140-2 Level 3 validated for SECRET-level workloads; Level 2 is generally acceptable only for SENSITIVE but UNCLASSIFIED material.

Audit logging: capturing API server events for compliance and forensics

The Kubernetes API server generates an audit log of every request it processes: who made the request, what verb and resource were involved, what namespace, whether the request succeeded, and -- depending on the audit level configured -- the full request and response body. This log is the authoritative record for answering the question "who did what in this cluster and when." For classified environments, comprehensive audit logging is not optional; it is a specific control requirement in RMF, JSIG, and equivalent frameworks, and the absence of adequate audit logs is typically a showstopper finding during an accreditation review.

The audit policy is a YAML file passed to the kube-apiserver at startup that maps resource types and verbs to audit levels. The four levels are None (no logging), Metadata (user, verb, resource, status -- no body), Request (adds the request body), and RequestResponse (adds both request and response bodies). A compliance-grade policy captures RequestResponse for Secrets, ConfigMaps, Roles, RoleBindings, ClusterRoles, ClusterRoleBindings, and ServiceAccounts -- the resources whose modification could indicate privilege escalation or credential theft. Pod exec and attach calls must also be captured at RequestResponse level, as these are the primary vectors for interactive lateral movement in a compromised cluster. All other resources can be logged at Metadata level, which produces a complete access record without the storage overhead of capturing every application payload.

Audit logs stored only on the control-plane node are vulnerable to tampering by a compromised cluster administrator. A defense-grade audit architecture ships logs to an external destination that the cluster itself cannot write to or delete: a SIEM (security information and event management system), an append-only S3-compatible object store with object-lock retention, or a dedicated syslog forwarder to an air-gapped log aggregation infrastructure. The log shipper -- a Fluentd or Fluent Bit DaemonSet on control-plane nodes -- must run with a Kubernetes service account that has no permissions on the cluster objects being logged, so a compromised shipper cannot cover its own tracks by modifying audit policy or deleting log files.

Image scanning and supply chain security in classified container registries

Every container image deployed into a classified cluster is a potential supply chain attack surface. An image pulled from a public registry without inspection may contain known-vulnerable library versions, embedded credentials, or malicious code introduced during the build pipeline. Defense programs must operate a private container registry that is isolated from the public internet, requires authenticated access, and enforces vulnerability scanning and image signing before any image is admitted to the cluster.

Image vulnerability scanning tools such as Trivy or Grype analyze each image layer against the OSV advisory database and vendor security bulletins, producing a list of CVEs with severity scores and affected package versions. In a classified CI pipeline, scanning runs as part of the image build process; images that contain Critical or High-severity CVEs are blocked from being pushed to the production registry until the vulnerabilities are remediated or formally accepted as risks. The scan results are stored alongside the image in the registry metadata and referenced in the accreditation evidence package as proof that the software inventory is known and reviewed.

Image signing adds a cryptographic assertion that a specific image digest was produced by a specific build pipeline and has not been modified since signing. The Sigstore project's cosign tool supports signing with a key stored in an HSM or KMS, producing a signature attestation that is stored in the registry alongside the image. The Kubernetes admission webhook -- using a policy engine such as Kyverno or OPA Gatekeeper -- verifies the signature before any pod is scheduled. This chain of custody from build to deployment is precisely what supply chain security frameworks require: every workload running in the cluster can be traced to a specific signed build artifact, and unsigned or tampered images are rejected at the admission layer rather than discovered during a post-incident forensic review.

Accreditation pathway: getting a Kubernetes cluster through ATO or equivalent

An Authority to Operate for a Kubernetes cluster is not a single document but a package of evidence assembled to demonstrate that the system meets the security controls specified in the applicable framework -- Risk Management Framework (RMF) for US federal programs, JSIG for joint intelligence systems, or program-specific equivalents for allied nation defense procurement. The authorizing official reviews this package and makes a risk-acceptance decision. Understanding what the package must contain is essential for planning the accreditation timeline, because gaps discovered late in the review process can delay fielding by months.

The System Security Plan is the central document. For a Kubernetes cluster, the SSP must describe the cluster architecture (control-plane node count and placement, etcd topology, worker node pools, network topology), the node hardening configuration with references to the kube-bench compliance report, the encryption configuration for etcd, the RBAC model (which service accounts have which permissions and why), the network policy architecture, the image provenance and signing chain, and the audit log forwarding architecture. Each control in the applicable baseline is either satisfied (with a reference to the evidence), not applicable (with a justification), or open (with a compensating control or POA&M entry).

Continuous monitoring is a condition of most ATOs rather than a one-time gate. The cluster must be enrolled in a configuration management system that detects drift from the hardened baseline, a vulnerability management process that tracks CVEs in deployed images and node OS packages against remediation SLAs, and a log review process that monitors audit events for anomalies. Automated tooling -- kube-bench scheduled as a Kubernetes CronJob, image re-scanning on a nightly schedule, SIEM alerting rules for suspicious API server patterns -- produces the continuous monitoring evidence without requiring manual effort for every review cycle. Programs that build this automation before the initial ATO submission are in a much stronger position for reauthorization than those that treat continuous monitoring as a post-authorization afterthought.