Skip to main content
INS // Insights

Air-Gapped Kubernetes Deployment Guide

Updated April 2026 · 7 min read

Deploying Kubernetes in a disconnected, air-gapped classified environment introduces a class of operational challenges that simply don't exist in standard commercial or even GovCloud deployments. Container registries, Helm chart repos, operator images, and package managers all assume outbound internet connectivity. In a disconnected environment at IL4, IL5, or above, that assumption breaks everything.

Rutagon has built and operated production Kubernetes environments under these constraints. This article covers the architectural patterns that make air-gapped K8s deployable and maintainable — not just theoretically possible.

The Core Challenge: Everything Assumes the Internet

Standard Kubernetes tooling assumes connectivity at multiple layers:

  • Container images: docker pull, crictl pull, and Kubernetes image pulls need a reachable registry
  • Helm charts: helm repo add, helm fetch, and helm install reach out to chart repositories
  • Operators and CRDs: Operator Lifecycle Manager (OLM) and similar frameworks pull from external registries
  • OS packages: apt, yum, and dnf need repository mirrors for node-level package management
  • RBAC and webhook validation: Some admission controllers phone home for CRL/OCSP checks

In an air-gapped environment, every one of these must be resolved before the environment functions. The solutions are known, but the interdependencies require careful sequencing.

Pattern 1: Private Registry with Full Mirror

The foundational pattern is a private container registry deployed inside the air-gapped boundary that mirrors everything your cluster needs.

Registry options for classified environments:

  • Harbor: Open-source, CNCF project. Strong RBAC, image scanning integration, replication policies. Most commonly seen in production government deployments.
  • Sonatype Nexus: Proxies multiple artifact types (containers, Helm, Maven, npm, pypi) — useful when you need one tool to manage all artifact types.
  • AWS ECR (within GovCloud boundary): Works well for GovCloud deployments; pull-through cache from public.ecr.aws for approved base images.

Mirror strategy:

The registry must be pre-populated — either via an automated sync process that runs before air-gap activation, or via physical media transfer (sometimes called "data diode transfer" or "sneakernet") for environments that prohibit any inbound network path.

Catalog every image needed: base OS images, sidecar images (Istio, Fluentd, OpenTelemetry collector, cert-manager), application images, and operator images. Build a manifest. Mirror using tools like skopeo copy which can transfer between registries or to/from a tarball for transport.

For clusters using containerd, configure registry.mirrors in config.toml to redirect all pulls through the internal registry — this means no code changes needed in deployment manifests when moving between connected and disconnected environments.

Pattern 2: Offline Helm Repository

Helm charts are the de facto package manager for Kubernetes workloads in government environments. In an air-gapped environment, the standard helm repo add + helm install flow fails because it reaches external repositories.

Offline Helm setup:

  • Download charts to local storage in a connected staging environment: helm pull {repo}/{chart} --version {version} produces .tgz archives.
  • Host a local Helm repo using a simple static file server (nginx or S3-compatible API) serving index.yaml + chart archives. helm repo index . generates the index from a directory of chart archives.
  • Configure clusters to point at the internal Helm repo URL.

This is straightforward but requires discipline around versioning — an air-gapped environment cannot automatically pull chart updates, so version management becomes a manual (or automated, via a sync pipeline in the staging environment) process.

Pattern 3: STIG-Hardened Node Baseline

Kubernetes nodes in classified environments typically must meet DISA STIG requirements. This is non-trivial — the Kubernetes STIG (available at public.cyber.mil) has over 90 checks across cluster configuration, API server hardening, etcd encryption, and network policy enforcement.

Critical STIG items for disconnected environments:

V-242378 — Anonymous API server access disabled:

# kube-apiserver configuration
--anonymous-auth=false

V-242379 — Audit logging enabled:

--audit-log-path=/var/log/kubernetes/audit.log
--audit-log-maxage=30
--audit-log-maxbackup=10
--audit-log-maxsize=100
--audit-policy-file=/etc/kubernetes/audit-policy.yaml

V-242380 — etcd encryption at rest:

# encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}

Node hardening: Apply CIS Kubernetes Benchmark Level 2 on node OS. For RHEL-based nodes, this means disabling IPv6 if not used, locking down kubelet API access, disabling anonymous kubelet auth, and ensuring FIPS 140-2 validated cryptography modules are active.

FIPS compliance in containers: When FIPS mode is enabled at the OS level, ensure your container images use FIPS-validated crypto libraries. UBI9 (Red Hat Universal Base Image 9) with FIPS-enabled packages is a common choice for classified workloads. Go applications compiled with GOEXPERIMENT=boringcrypto use FIPS-validated BoringCrypto instead of the standard Go crypto library.

Pattern 4: NetworkPolicy Default-Deny Baseline

In a classified environment, Kubernetes NetworkPolicy isn't optional — it's a compensating control for workload isolation. The baseline should be default-deny, with explicit allow policies for every necessary communication path.

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

Apply this to every namespace. Then layer explicit ingress/egress policies for allowed communication:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-internal-api
  namespace: mission-system
spec:
  podSelector:
    matchLabels:
      app: mission-api
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

For NIST 800-53 SC-7 compliance, this provides the boundary protection documentation artifact — NetworkPolicy YAML is the machine-verifiable evidence that access is restricted.

Delivery: Media Transfer and Sync Pipeline

The operational reality of an air-gapped environment is that updates require a deliberate process. For most classified environments, this means:

  • Connected staging environment: Mirror current image and chart versions, run security scans (Trivy, Grype), validate against approved image list.
  • Transfer media: Signed archive transferred via approved data transfer method into the classified environment.
  • Disconnected registry update: Load images and charts from transfer media into Harbor, update Helm repo index.
  • Cluster rolling update: Apply updated deployments with kubectl rollout restart or Helm upgrade.

The staging-to-air-gapped pipeline is a critical piece of the delivery architecture — not an afterthought. Building it as a first-class automated pipeline (with approvals, scan gates, and signature verification) is what makes air-gapped Kubernetes operationally sustainable at scale.

Rutagon's Approach

Rutagon designs Kubernetes platforms with air-gap deployment as a first-class requirement, not a retrofit. Production systems built on this architecture have supported classified workloads with full STIG compliance, automated ConMon reporting, and repeatable deployment pipelines that handle the media transfer and registry sync process at scale.

Rutagon Engineering Capabilities →

DevSecOps and Compliance Architecture →

Frequently Asked Questions

Can Kubernetes operators work in an air-gapped environment?

Yes, but they require additional pre-staging. Operators running via OLM need their operator catalog (CatalogSource) mirrored. For disconnected environments, build a custom operator catalog bundle from mirrored images and host it in the internal registry. oc mirror (on OpenShift) and operator-sdk bundle tooling supports this pattern.

What Kubernetes distributions are most commonly used in classified environments?

Red Hat OpenShift (OCP) is dominant in IL4/IL5 environments because of its RH certification, UBI image ecosystem, and FedRAMP-authorized deployment options. K3s and RKE2 (Rancher Government Solutions) are common for edge and tactical environments where a lighter footprint is needed. Vanilla upstream Kubernetes is less common due to the additional hardening work required to meet STIG requirements versus distributions that ship with hardening applied.

How do certificate management and rotation work in an air-gapped cluster?

cert-manager can function in an air-gapped environment if deployed with images pre-mirrored. However, OCSP and CRL checks for external CAs must be disabled or routed to an internal responder. Internal PKI (using a HashiCorp Vault-based CA or AWS Private CA in GovCloud) avoids external trust anchors entirely. Kubernetes internal certificate rotation is configured via --rotate-certificates=true on the kubelet.

What are the STIG compliance checking tools that work offline?

OpenSCAP with DISA STIG content downloaded in advance is the primary tool. oscap runs locally against a node without network access. For Kubernetes-specific scanning, kube-bench (CIS Benchmark) runs locally as a Kubernetes job. Twistlock/Prisma Cloud and Aqua Security both support air-gapped deployments with offline policy packs for classified environments.

How does Rutagon handle updates to air-gapped clusters in production?

Rutagon maintains a staged delivery pipeline where updates are validated in a connected staging environment, signed, scanned, and bundled for transfer. The transfer and load process is automated where the classified environment allows, and documented as a reproducible runbook where it cannot be. Update frequency, testing rigor, and approval gates are tailored to the program's ATO maintenance requirements.