Package for the Enclave
Last reviewed
AdvancedWhat you'll learn
~18 min- Vendor everything: provider mirrors, rewritten modules, and pinned binaries in one self-sufficient archive
- Split tooling into low-side/high-side script pairs that rehearse the enclave run
- Ship the compliance statement and evidence folder that let the package speak for itself
The network is not coming with you
Module 5 is where Meridian’s software physically leaves home. The destination enclave — the high side — has no route to the internet, no registry access, no provider APIs, and no sympathy: everything your deployment needs must arrive inside the package, or it does not exist there. The engineering discipline this forces is vendoring taken to its logical conclusion, and the reference implementation (a production air-gap IaC package, 2026-live) shows it takes three distinct disciplines, because dependencies hide in three distinct places:
ONE ARCHIVE, THREE VENDORING DISCIPLINES:
1. PROVIDER MIRROR IaC providers vendored as a local network mirror + a config file (.terraformrc-class) that points resolution AT the mirror - the tool believes it is online; it is not
2. MODULE COPY-AND- every remote module reference REWRITTEN to a REWRITE local relative path - source addresses that assume a registry are edited, not wrapped; the archive is the registry now
3. PINNED BINARIES the tools themselves (CLI binaries, exact versions) + SHASUMS file - the enclave runs YOUR toolchain, verified, not whatever it hasWhy three and not one: a mirror does not catch module references (they resolve at a different layer), and neither catches the binary that interprets both. Teams that vendor one layer discover the other two on the high side, where discovery costs a transfer cycle (next lesson explains why that’s expensive). The supply-chain pinning mechanics — lock files, what they do and don’t cover, recoverable vendoring — are the DevSecOps Foundations training’s lane (The IaC Supply Chain — in short: pin exact versions and vendor what you can’t re-fetch); this lesson is that discipline with the re-fetch option surgically removed.
The script pair: rehearse the run you cannot attend
The package ships two sibling scripts, and the pairing is the design: a low-side script that builds the archive and then executes a full dry-run deployment against the vendored contents — proving the archive self-sufficient while you can still fix it — and a high-side script that performs the real run inside the enclave using only what arrived. The two share structure deliberately: the low-side rehearsal is the high-side run, minus the classification. Every divergence between them is a place where the rehearsal can pass while the real run fails — which is why the reference pair keeps them in lockstep, reviewed together.
This is the deepest habit change of enclave delivery: you will not be in the room. An operator you may never meet runs your script under constraints you don’t fully know. Anything interactive, environment-assuming, or improvised is a failure already shipped. The rehearsal discipline is how you debug a deployment before it happens.
The package speaks for itself
Two more artifacts ride in the archive, and they’re Module 2-3’s disciplines in travel form. The compliance statement: a metrics header, per-family tables mapping each control to its implementation, and — the part worth copying verbatim as a pattern — a resource-coverage section tying controls to the IaC standards file by file and line range (Lesson 2.2’s traceability, so the high-side reviewer audits code, not claims), with verification split into automated CLI checks with expected values versus manual query procedures for what only the enclave can confirm. And the evidence folder: a dated smoke-run record — a human-readable rollup table (check, result, control) over per-check machine-readable results — the low-side rehearsal’s proof, packaged so the high side knows what “working” looked like before transfer.
Prompt first: build and prove the archive
Build the enclave package for [deployment repo]:1) vendor all three layers - provider mirror + resolution config, module references rewritten to local paths (list every rewrite), tool binaries pinned with SHASUMS - then PROVE self-sufficiency: run the full plan/validate cycle in a network-disabled container and fail the build on ANY outbound attempt;2) generate the low/high script pair from one template so they cannot drift - parameterize only what genuinely differs, and list those parameters for review;3) emit the compliance statement: control-to-file-and-line-range coverage table from our catalog (Lesson 2.1), verification split automated-with-expected-values vs manual-procedure;4) run the rehearsal, capture the smoke-run rollup + per-check JSON into evidence/, dated.The network-disabled proof in step 1 is the step teams skip and regret: an archive that has never been tested offline is an archive that is probably self-sufficient — and “probably” is a word you find out about on the wrong side of a guarded gate.
Read your high-side script as its operator: every prompt for input, every assumed environment variable, every error message that says ‘see logs’ (which logs? where?) is a question the operator cannot ask you. The reference pattern’s answers: no interactivity anywhere, environment declared and checked up front with named failures, every error message carrying its own remediation. Write the runbook INTO the tooling - the enclave does not have your Slack.
Meridian's archive passes its low-side rehearsal. On the high side, the deployment fails: an IaC module referenced a helper module by registry address, which resolved silently on the low side (the rehearsal machine had cached credentials and network access) and cannot resolve in the enclave. Which discipline failed, and what is the systemic fix?
Key takeaway
Enclave packaging is vendoring with no undo: three disciplines (provider mirror plus resolution config, module references rewritten local, binaries pinned with checksums) proven by a network-disabled rehearsal — because the rehearsal is only as honest as its isolation. Ship the low/high script pair generated from one template, a compliance statement with line-range traceability and split verification, and the dated evidence of the run that worked. You will not be in the room; the package must be. Next: the transfer itself — where trust becomes structural.