Repository navigation
spike: decide the registry-layer question — pull-through cache, tenant RBAC, and the pull-path failure mode #2895
Description
🤖 Generated by the Agentic Engineer
Timeboxed decision spike for #2894. Output is a recorded decision plus follow-up issues, not a PR.
Question
Does a registry layer earn its operational cost on this platform, and if so in what narrowest form?
Why a spike rather than straight to implementation
The case is genuinely mixed. Two of the four usual arguments (air-gap, data sovereignty) do not apply
to us; two (pull-through caching, multi-tenant RBAC) are backed by real open issues. Against that,
Harbor is stateful and would sit in the pull path of every workload in the estate. That trade deserves
a decision with evidence attached, especially since #785 and #822 were closed NOT_PLANNED with no
rationale recorded and would otherwise simply be re-litigated a third time.
What to establish
- Quantify the RBAC pain. How many distinct credentials/workarounds exist today across tenants,
and which of Scope tenant GHCR pull credentials to authorized packages #2889 / Single source of truth for the ghcr pull credential (OpenBao + ExternalSecret) #2613 / Skip the GHCR-auth reboot for nodes whose containerd already booted with the current credential #2638 / Align Coroot API-key wiring and registry egress #2685 a project-scoped registry would actually close. If it
closes fewer than expected, the strongest argument weakens. - Quantify the upstream coupling. Count registry-caused CI/pull failures over a recent window
(Docker Hub timeouts, rate limits, upstream 5xx). A pull-through cache is justified by a real rate,
not by the possibility. - Resolve the availability question — this is the decisive one. Determine whether the pull path
can be made to degrade to upstream registries when the registry layer is unavailable. Establish
concretely how the cluster recovers from cold start if the registry itself cannot be pulled.
If there is no credible answer here, the spike should recommend declining, regardless of how
attractive the other benefits look. - Check for overlap, not just fit. Where Harbor's scanning would duplicate Kubescape (roadmap: Kubescape security stack → 100% and hold (posture · CVE · runtime) #2447), and
how it interacts with Kyverno admission and cosign verification (security: tighten cosign subject matchers at the image-verification layer #2815, First-party image pull verification does not block an unsigned first-party image #2856). Two gates that can
disagree about the same image is a failure mode, not defence in depth. - Cost the operations honestly. PostgreSQL + Redis + object storage on Longhorn: backup/restore,
upgrades, and failure drills, on a platform whose recent pain has been operational and
storage-shaped (Roadmap: a resilient, current, well-abstracted GitOps platform #2043). - Consider the cheaper alternatives on equal terms, so this is a comparison and not a
justification: a plain pull-through mirror (containerd registry mirroring, or a lighter registry)
that captures the caching benefit without owning first-party image storage or entering the critical
path in the same way.
Acceptance criteria
- A written decision on roadmap: decide whether a registry layer (Harbor) earns its place in the supply chain #2894 — adopt / adopt-narrowly / decline — with the evidence for each
of the six points above. - The availability/failure-mode analysis is explicit and includes the cold-start case.
- The alternatives in (6) are evaluated on the same terms, not dismissed.
- If adopting: follow-up issues filed and linked as children of roadmap: decide whether a registry layer (Harbor) earns its place in the supply chain #2894.
- If declining: rationale recorded on roadmap: decide whether a registry layer (Harbor) earns its place in the supply chain #2894 and cross-referenced from Set up Harbor pull-through for all images #785 and Configure Homelab to pull all images as OCI through Harbor #822 so the closure
is finally reasoned rather than swept.
Size: small — investigation and a decision record; no production change.
Part of #2894
Generated by Claude Code
Activity
coderabbitai commentedon Aug 2, 2026
🔗 Related PRs
#2519 - docs(tenant): record KRO as the chosen Tenant abstraction (ADR) [merged]
#2633 - fix(deploy): verify incoming image on Talos nodes [merged]
#2794 - fix(opencost): restore usage metrics [merged]
#2860 - security(k8s): record an explicit service-account-token verdict per workload [merged]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
chore: agent-claim #2895 nonce=2af64bc588a9b4d96ef275a7e2fee55c
devantler commentedon Sep 23, 2026
Spike complete. The decision is decline: no registry layer, neither Harbor nor a pull-through cache, for now. The evidence for all six points, including the cold-start analysis and the cheaper alternatives compared on the same terms, is recorded on #2894: #2894 (comment)
Generated by Claude Code