Petra: Hardened Kubernetes for Compliant and Air-Gapped Environments
A layered approach to secure Kubernetes delivery across classification boundaries
Abstract
Deploying and maintaining Kubernetes in regulated, disconnected, and multi-classification environments remains one of the most operationally complex challenges in defense and intelligence computing. The existing ecosystem addresses this problem in fragments -- packaging tools that lack an operating system, platforms that require external delivery mechanisms, and distributions that demand extraordinary cost and complexity.
Petra packages Flatcar Container Linux, FIPS-validated k3s, and a curated addon stack into a single deployable unit. Every container image originates from Chainguard with SLSA Build Level 3 provenance and cosign signatures. Air-gap delivery is a first-class capability: signed bundles transfer through hardware data diodes, guards, or AWS Diode with cryptographic verification at every stage.
The Problem Space
Organizations operating at FISMA Moderate, FedRAMP High, and DoD Impact Levels IL4 through IL6 must satisfy hundreds of security controls from NIST 800-53 Rev 5. These controls mandate FIPS-validated cryptography, verified software supply chains, immutable infrastructure, continuous monitoring, and least-privilege access.
Air-gapped environments add further constraints: no container images pulled at runtime, no Helm repositories reachable, no Git repositories accessible, no certificate authorities contactable. Current approaches -- manually compiling image lists, mirroring with crane or skopeo, carrying USB drives through security checkpoints, and rewriting manifest references -- are manual, error-prone, and difficult to audit.
Cross-Domain Solutions (CDS) transfer files, not container registries. Any air-gap delivery solution must produce a self-contained, signed file artifact that can traverse a CDS without modification.
Petra Architecture
Petra is built as four independent layers:
- Layer 1: OS -- Flatcar Container Linux (immutable root, A/B partitions)
- Layer 2: Runtime -- k3s FIPS (Go 1.24 native FIPS, CAVP A6650, single binary, embedded etcd)
- Layer 3: Addons -- Cilium, Flux, Gatekeeper, Tetragon, cert-manager, and more, managed by Flux
- Layer 4: Applications -- Customer workloads via Flux from bundled manifests
Two provisioning models share the same hardened base: standalone mode (direct AWS SDK) and CAPI mode (Cluster API for fleet management).
Air-Gap Delivery
petra bundle create produces a signed tar.zst archive containing OCI images, Helm charts, platform manifests, and metadata. Every image is verified (cosign), scanned, and digest-pinned before inclusion. The bundle is signed with cosign sign-blob.
Bundles are compatible with all CDS types: sneakernet, hardware data diodes, guards, and AWS Diode. On the disconnected side, petra bundle load verifies the signature, loads images for distribution, and triggers Flux reconciliation.
AWS Diode Integration
AWS Diode is a fully managed CDS service that enables one-way S3-to-S3 transfers between AWS security regions. Petra's pipeline: build bundle, upload to S3, trigger Diode transfer, verify on landing, load into cluster. Fully automatable with CloudTrail audit on both sides.
Defense-in-Depth Security
No SSH. IMDSv2 enforced. FIPS mandatory. Immutable OS. eBPF networking (Cilium) and runtime security (Tetragon). OPA Gatekeeper admission policies. Sigstore signature verification at admission. kube-bench CIS validation. Every running container traceable from Chainguard source through CDS transfer to runtime.
Competitive Comparison
Target Environments
- AWS GovCloud (IL4/IL5) -- Primary target
- AWS SC2S / C2S (IL6 / Top Secret) -- Via AWS Diode
- Commercial AWS -- Development and staging
- Future: Azure Government, bare metal, VMware, ISO