Skip to content

Milestone 2 completion summary

Status: Milestone 2 source implementation and local end-to-end acceptance are complete. The remaining work is environment-specific deployment evidence collection when an Azure high-side target is available.

Milestone 2 proves the receiver side of the low-to-high Linux update workflow: a connected low-side Pulp instance can export an approved repository snapshot, the export can be wrapped in a signed transfer bundle, and a disconnected high-side Pulp instance can receive, import, publish, and serve that content to Linux clients.

Completed capabilities

Capability Status Evidence
Local low-side Pulp sync and publish Complete docs/evidence/local-e2e/20260425T120532Z/
Low-side client consumption of Pulp updates Complete docs/evidence/local-e2e/20260425T131149Z-apt-client/
Signed transfer bundle build and verify Complete automation/bootstrap/transfer_bundle.py, tests/test_transfer_bundle.py
High-side receive staging with receipt generation Complete automation/bootstrap/transfer_bundle.py receive
Pulp-to-Pulp export/import between isolated instances Complete docs/evidence/phase2-airgap/20260425T160539Z/report.md
High-side publication and client install Complete docs/evidence/phase2-airgap/20260425T160539Z/screenshots/
Local CI validation for transfer and Compose checks Complete automation/validate-ci.sh
High-side platform network posture review Complete for source controls docs/evidence/phase2-high-side-public-access-audit.md

Air-gap workflow validated

The Phase 2 air-gap validation used two isolated local Pulp stacks and a fresh Ubuntu client container:

  1. Build a small APT fixture repository containing airgap-patch-demo_1.0.1_amd64.deb.
  2. Sync and publish that repository through the low-side Pulp instance.
  3. Export the low-side repository version with the Pulp core exporter.
  4. Build and verify a signed transfer bundle containing the Pulp export.
  5. Receive the bundle into the high-side import root and write a receipt.
  6. Run high-side Pulp import-check, import the export, publish it, and serve it from a stable content URL.
  7. Configure a clean Ubuntu client to install airgap-patch-demo from the high-side Pulp content endpoint only.

The captured client proof is:

airgap-patch-demo   1.0.1
airgap-patch-demo version 1.0.1 installed from high-side Pulp

Public repository review notes

The committed evidence is intentionally limited to source-controlled runbooks, generated screenshots, fixture metadata, and non-sensitive Pulp task outputs. The evidence set was reviewed for public repository readiness:

  • no private signing keys are committed,
  • local .env files are ignored and not committed,
  • screenshots and reports describe observed command/API results rather than inferred behavior,
  • exploratory OpenAPI dumps and large probe files were removed from the evidence tree,
  • diagrams are maintained as readable SVGs under docs/architecture/,
  • timestamped run evidence is linked from this canonical summary instead of being the only documentation entry point.

Platform security status

High-side Redis and Key Vault source controls now use deny-by-default public network posture with private endpoint/private DNS paths in the high-side infrastructure. ACR and Service Bus remain documented Milestone 2 residual risks because their private endpoint posture requires Premium SKU and additional managed-identity/runtime migration work.

See:

  • docs/evidence/phase2-high-side-public-access-audit.md
  • docs/evidence/phase2-platform-security-checklist.md
  • docs/security/secret-inventory.md

Canonical diagrams

  • docs/architecture/phase2-operator-transfer-workflow.svg
  • docs/architecture/phase2-airgap-validation-flow.svg
  • docs/architecture/pulp-l2h-lifecycle.svg
  • docs/architecture/pulp-l2h-topology.svg

Validation commands

The current Milestone 2 source state is validated with:

python3 -m unittest discover -s tests -p 'test_*.py'
docker compose --env-file runtime/compose/.env.example -f runtime/compose/docker-compose.yml config --quiet
bash automation/validate-ci.sh

automation/validate-ci.sh runs Python syntax checks, shell syntax checks, Python unit tests, YAML parsing, Docker Compose rendering, local-only file checks, secret-pattern scanning, and Bicep template validation when the Azure CLI is available.

Remaining post-M2 evidence work

The core Milestone 2 transfer mechanics are locally proven. Future work should focus on deployment-specific evidence rather than redesign:

  1. collect Azure high-side deployment evidence after an approved test deployment,
  2. validate high-side Redis and Key Vault private endpoint DNS/runtime access from the deployed host,
  3. close accepted residual-risk follow-ups for ACR Premium Private Link and Service Bus Premium/managed-identity migration,
  4. extend the same export/import proof from the small fixture repository to the approved production repository matrix.