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.

Build Host Requirements​

  • OS: Ubuntu 24.04 LTS (recommended)
  • Hardware: 4+ CPU cores, 8+ GB RAM, 100 GB+ free disk, 10+ Mbps internet
  • Software: Python 3.12+, Git 2.30+, pip
  • Optional: Zarf CLI 0.40+, Cosign 2.0+, Docker/Podman

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.

Bastion Services​

The bastion serves three roles:

ServicePortFunction
Container registry35000OCI images for kubelet, FluxCD, platform services
Nginx file server80OS packages (/debs), Python wheels (/pypi), K8s binaries (/files)
Gitea (optional)3000Local Git server for GitOps repositories

Ports are configurable via Zarf variables:

VariableDefaultDescription
SSH_USERdeployerSSH user for bastion operations
INSTALL_PATH/opt/opencenterBase installation directory
REGISTRY_PORT35000Container registry listen port
NGINX_PORT80File server listen port

Bastion Requirements​

  • OS: Ubuntu 24.04 LTS
  • Hardware: 4+ CPU, 8+ GB RAM, 100 GB+ disk, 1+ Gbps to cluster nodes
  • Software: Zarf CLI 0.40+, Docker or Podman, OpenSSH client
  • Ports open to cluster nodes: 35000 (registry), 80 (nginx), 3000 (Gitea), 22 (SSH)

Cluster Node Requirements​

  • Control plane: 4+ cores, 8 GB RAM, 50 GB disk
  • Worker (production): 16+ cores, 32+ GB RAM, 200+ GB SSD
  • Pre-installed: Python 3.12+, OpenSSH server
  • Ports: 6443, 2379-2380, 10250, 10256, 179, 4789/UDP

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, file server, and optionally Gitea.
  5. Kubespray and FluxCD on target nodes pull exclusively from the bastion.

Zarf Package Components​

The generated package contains four components:

ComponentContents
bootstrap-toolsCLI tools (helm, k9s, stern, yq, jq, kubectl, kubectx), target scripts, Terraform mirror
kubespray-coreKubespray playbooks, K8s binaries, OS package repository, Python wheels
k8s-images139+ container images loaded into local registry
deploy-clusterBastion setup orchestration (nginx, registry, Python venv, Gitea)

Trade-offs​

  • The three-zone model adds transfer latency (hours to days depending on courier logistics). Plan update cycles accordingly.
  • Zone A builds should be reproducible so that a second build of the same versions.env produces a consistent 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​