Skip to content
Agile Defense

Curriculum / Platform Administration & Security — Defense Edition

CAPSTONEUnit 9unit-09

Air-Gapped Release with Apollo

not started~300 min
Plan delivery of the secured platform into a disconnected enclave with Apollo — Products/Releases/Versions, Release Channels, hub-and-spoke, and Cross Domain Solution / physical-media transfer.

Introduction

Scenario: Your multi-program defense org has finished securing the mission platform — Organizations, Markings, CBAC, Restricted Views, governance, and resource protection are all in place. Now you must plan how that secured platform is delivered and kept current inside a disconnected mission enclave that has no network path back to the managing environment.

This capstone unit shifts from securing the platform to delivering and operating it across a network boundary. Apollo is Palantir's continuous-delivery and orchestration system: it packages software as Products, tracks each version as a Release, and uses a hub-and-spoke model in which an Apollo Hub issues Plans and the Spoke Environments (your enclaves) execute them and report telemetry back. For a defense admin, Apollo is the discipline that turns 'we built a secure instance' into 'we can ship versioned, reviewable upgrades into an isolated enclave and roll them back if a deployment fails.'

It matters because the enclave you are delivering into is intentionally cut off. There is no continuous connection for the Hub to push to, so promotion has to be deliberate: a Release moves through Release Channels — DEV, then RELEASE_CANDIDATE, then RELEASE — so that only vetted, stable versions ever cross into the mission environment. You will document the Product/Release/Version identity (Maven coordinates of the form group:artifactId, and group:artifactId:version for a specific Release), the channel promotion path and what gates each hop, the Hub-and-Spoke topology that manages the enclave, and finally the air-gapped transfer modality that physically or logically carries the bits across the boundary.

Because Apollo is operated and configured outside the Foundry admin/security APIs you used in earlier units, every step here is a documented, self-attested checkpoint — there is no READ API in scope that can confirm a Product, a channel promotion, a Spoke's Reported State, or a transfer method. Treat the deliverable as a written release plan that a reviewer and your security authority can sign off on. Several specifics below (the three default channels, and the Cross Domain Solution / physical-media transfer options) are cited at partial confidence and are flagged as ASSUMPTION TO CONFIRM against the official Apollo documentation before you treat them as guaranteed product behavior.

Capability focus: Apollo Products/Releases/Versions; Release Channels (DEV/RELEASE_CANDIDATE/RELEASE); hub-and-spoke; air-gapped/CDS delivery. · Artifact: An Apollo release plan: product (group:artifactId), target spoke, promotion channel path, and the air-gapped transfer modality.

Key concepts

  • Products, Releases, and Versions: An Apollo Product is a deployable software component identified by Maven coordinates (group:artifactId). Each version published to the Product catalog is a Release, identified as group:artifactId:version. Apollo functionality requires an orderable version — you deploy a specific Release, not an abstract product.
  • Apollo Release Channels: Channels group Product/Module Releases by attributes such as stability. The three default channels a Release may be added to on publish are DEV, RELEASE_CANDIDATE, and RELEASE; promotion through them is how you gate which versions are eligible to reach a sensitive enclave. (Partial-confidence — re-confirm the channel names and behavior against the Release Channels docs page before treating as fixed.)
  • Hub-and-spoke topology: Apollo uses a hub-and-spoke model. The Apollo Hub issues Plans (the desired-state changes) and receives Reported State telemetry from Spoke Environments. Each Spoke runs agents that poll the Orchestration Engine and execute Plans locally; a Plan that fails triggers a rollback Plan so the Spoke returns to a known-good state.
  • Air-gapped / disconnected delivery: Apollo supports cloud, on-premises, and disconnected (air-gapped) environments. For disconnected enclaves it can transfer updates via a Cross Domain Solution (aligned with Raise the Bar guidance), use delta/opportunistic updates and local caching on degraded networks, and fall back to approved physical media for fully disconnected enclaves. (Partial-confidence — CDS/physical-media specifics must be confirmed against an official /docs/apollo page before being treated as product behavior; the IL-level and Raise the Bar alignment are partial claims, not guarantees.)
  • Plans, Reported State, and rollback: A Plan is the unit of orchestrated change Apollo computes and dispatches; the Spoke's agents reconcile toward it and continuously report observed state back to the Hub. This telemetry-and-rollback loop is what makes upgrades in an isolated enclave safe to attempt, since a failed Plan is automatically reverted rather than left half-applied.

Companion video

Apollo air-gapped release walkthrough (placeholder) · open on YouTube

Hands-on activity

each step validates · the unit completes when all steps pass
  1. 1

    Document the Apollo product, release, and version model

    Document the Apollo Product/Release/Version identity for the platform you are shipping into the enclave. Record the Product as Maven coordinates (group:artifactId), and the specific Release you intend to deliver as group:artifactId:version — Apollo requires an orderable version, so you deploy a concrete Release rather than 'the latest.' Note in your plan which Release version is the target and why (the build that carries the secured configuration from the earlier units). This is a self-attested checkpoint: Apollo has no Foundry-style public READ API in scope, so no automated check can confirm the Product or Release exists (APOLLO-NO-READ-API). State the coordinates explicitly so a reviewer can verify them against the Product catalog by hand.

    not startedself-attested

    Self-attested: the Product (group:artifactId), its Release/version, and that Apollo needs an orderable version.

  2. 2

    Document the Release Channel promotion pipeline

    Map the Release through the Release Channel promotion pipeline: DEV → RELEASE_CANDIDATE → RELEASE. For each hop, record what gates promotion — what testing, review, or stability bar a version must clear before it is eligible to advance toward the mission enclave — so that only RELEASE-channel versions are considered for transfer across the boundary. This is a self-attested, documented checkpoint and is not API-confirmable here. Flag the channel names and promotion semantics as partial-confidence (ASSUMPTION TO CONFIRM): re-confirm DEV / RELEASE_CANDIDATE / RELEASE and their gating behavior against the official Apollo Release Channels docs page before you rely on them as exact product behavior.

    not startedself-attested

    Self-attested: the DEV → RELEASE_CANDIDATE → RELEASE channel path and promotion gates.

  3. 3

    Document the hub-and-spoke topology for the enclave

    Record the hub-and-spoke topology that will manage the enclave. Identify the managing Apollo Hub and the Spoke Environment that represents the disconnected mission enclave. Describe the operating loop: the Hub issues Plans (desired-state changes), the Spoke's agents poll the Orchestration Engine and execute those Plans locally, and the Spoke sends Reported State telemetry back to the Hub; a failed Plan triggers a rollback Plan so the Spoke recovers to a known-good state. Note how the telemetry path works given the enclave is disconnected (when and how Reported State is reconciled). This is a self-attested checkpoint — there is no API in scope that exposes a Spoke's Reported State or Plan execution, so a reviewer confirms the topology against your written plan, not a live read.

    not startedself-attested

    Self-attested: the managing Hub and the Spoke environment, telemetry/Reported State, and Plan execution/rollback.

  4. 4

    Document the air-gapped transfer modality

    Document the air-gapped transfer modality — the disconnected delivery path that carries the vetted Release across the network boundary. Choose and justify one: a Cross Domain Solution (aligned with Raise the Bar guidance) for controlled cross-boundary transfer; delta/opportunistic updates with local caching for intermittently or degraded-connected networks; or approved physical media for a fully disconnected enclave. Specify that you bundle and send only what the Spoke needs. This is a self-attested checkpoint with no API confirmation in scope. Flag it clearly as partial-confidence (AIR-GAPPED-DELIVERY-SOURCE / ASSUMPTION TO CONFIRM): the CDS, Raise the Bar alignment, and physical-media details — and any impact-level (IL) claims — must be confirmed against an official /docs/apollo page before being treated as guaranteed product behavior. Maven Smart System is out of scope and must not appear in the plan.

    not startedself-attested

    Self-attested: the disconnected delivery path (Cross Domain Solution / delta updates + caching / approved physical media).