Skip to main content

Architecture & Zones

Purpose: For platform engineers, explains the three-zone security model (connected build host → transfer medium → disconnected site).

Concept Summary​

Air-gapped deployments split the world into three trust zones. Each zone has a distinct network posture, and data crosses zone boundaries only through controlled transfer points. The opencenter-airgap CLI operates in Zone A; the resulting Zarf artifact travels through Zone B; Zone C consumes it without ever reaching the internet.

Zone A — Factory (Connected Build Host)​

Zone A is the only environment with internet access. The build host downloads every dependency — container images, OS packages, Python wheels, Kubernetes binaries, Helm charts, and Terraform providers — and packages them into a single Zarf artifact.

Key properties:

  • Outbound HTTPS to public registries, package repos, and GitHub (see Firewall Whitelist).
  • No inbound connections required.
  • Build artifacts are signed with Cosign and include an SBOM.
  • Runs opencenter-airgap build to produce zarf-package-opencenter-airgap-amd64-*.tar.zst.

Zone B — Airlock (Physical Media Transfer)​

Zone B is the transfer boundary. No compute happens here — it is a physical or procedural control ensuring that only verified artifacts cross from connected to disconnected networks.

Transfer methods:

  • USB drive or external SSD
  • Optical media (DVD/Blu-ray) for write-once assurance
  • Secure courier with chain-of-custody documentation
  • Cross-domain solution (CDS) where approved by policy

Before transfer, verify the package checksum on the Zone A host:

sha256sum dist/zarf-package-opencenter-airgap-amd64-*.tar.zst > package.sha256

After transfer, verify on the Zone C bastion:

sha256sum -c package.sha256

Zone C — Field (Disconnected Site)​

Zone C has zero internet connectivity. A single bastion host receives the Zarf artifact and becomes the local source of truth for all dependencies.

The bastion serves two roles:

ServicePortFunction
Container registry35000OCI images for kubelet, FluxCD, platform services
Nginx file server80OS packages, Python wheels, K8s binaries

Target cluster nodes point their package managers and container runtimes at the bastion instead of the internet.

Data Flow Across Zones​

  1. opencenter-airgap build in Zone A produces a .tar.zst artifact with SBOM and signature.
  2. Operator copies the artifact to removable media (Zone B).
  3. Operator carries media to Zone C and loads it onto the bastion.
  4. zarf package deploy on the bastion unpacks components, starts the registry and file server.
  5. Kubespray and FluxCD on target nodes pull exclusively from the bastion.

Trade-offs​

  • The three-zone model adds transfer latency (hours to days depending on courier logistics). Plan update cycles accordingly.
  • Zone A builds must be fully reproducible so that a second build of the same versions.env produces a byte-identical artifact. See Reproducible Builds.
  • Zone C has no way to fetch missing dependencies at deploy time. If a component is missing from the artifact, the deployment fails. The opencenter-airgap validate command catches this before transfer.

Further Reading​