Moco 0.0.3: release and recovery evidence
Release v0.0.3 adds published
controller artifacts alongside the server. Source revision:
d3230a01676007350f3452f0ad6b2c79c6697cd5.
Release publication
completed successfully. The release contains both chart archives, release.json
and SHA256SUMS; the manifest records image and chart identities.
| Published image | Multi-platform index digest |
|---|---|
| ghcr.io/araihu/moco:0.0.3 | sha256:d6a8167c48c771884729405ff4a0d3c8f65bb1b69bbcb96c091745de6eade180 |
| ghcr.io/araihu/moco-controller:0.0.3 | sha256:b5a1ec66f8fc562584202c5e117de4af827acba5fd60bc082f516e72e7e04ffa |
Both indices include Linux amd64/arm64, provenance and SBOM attestations. Both released charts pin their respective image digest.
Published artifact acceptance
The vind + Calico + ESO run
passed 21 scenarios using the published images and charts, not rebuilt
application binaries. The test harness revision was
2b236a3319c7591cfd608a9a0e8e1fe4ff8a4a66. It verified release archive checksums,
OCI identities, installed chart versions and running image IDs.
Coverage included:
- Declarative tenant/vault/authorization creation, idempotence, drift repair, controller restart, credential refresh and CRD admission guards.
- Scoped authorization, ESO delivery to a consumer, special-character paths, binary Base64 decoding, invalid-token retention and CA repair.
- TLS certificate, reader-token and controller-token rotation with revocation; NetworkPolicy boundaries and protected metrics.
- Conditional updates with audit, automatic mirrored snapshots, root-key rotation/rewrapping, mirror failure readiness and recovery.
- Persistent data after pod replacement, offline restoration with historical keys, fresh ESO sync and retained resources after CR deletion.
Reproduce with make vind-test on a host suitable for vind; the workflow can
also run in release mode. See prerequisites and report fields.
Use make vind-source-test when testing current source changes.
Scope and limits
The acceptance cluster used static single-node RWO volumes. The mirror was a separate volume on the same Docker host. This proves application integration and recovery behavior under the tested faults; it does not demonstrate off-host durability, a particular CSI driver's fencing, multi-node availability or your homelab's recovery objectives. Production remains one SQLite writer. External KMS/HSM and high availability are not implemented.
Keep historical root keys and deployment credentials in separate custody, protect backups as sensitive data and rehearse a restore on your own storage. Recovery runbook · Production profile.