Validate the signed tenant artifact handoff

[devantler]

🤖 Generated by the Agentic Engineer

Summary

Bind the tenant scaffold's validation to the complete signed private-artifact handoff that current Platform registrations use: publishing, GHCR pull credentials, cosign verification, and Flux reconciliation.

Evidence and problem

At tenant-template main 1bd995f26445681a39309919ba0642806109301f and Platform main 6b67c9454e73fe7faf94d3be39bf874ba194b8e1, the existing gates cover schema validity, onboarding rename behavior, agent instructions, Kyverno admission, Pod Security, tenant RBAC, the KRO/manual namespace and impersonation envelope, and the generated network floor.

They do not bind the delivery chain between the template's cd.yaml, Platform's ghcr-auth ExternalSecret, the tenant ServiceAccount's image pull secret, the cosign-verifying OCIRepository, and the Flux Kustomization's source reference. A fresh tenant can therefore keep every current scaffold check green while drift either prevents private artifact pulls or widens the trusted artifact producer.

Affected audience: maintainers adopting the template and every tenant relying on the Platform to reconcile its signed OCI artifact on day one.

Hypothesis and success signal

If the existing live-Platform envelope gate validates the complete producer-to-reconciler chain, PR and weekly runs will reject credential miswiring and supply-chain widening before they reach a tenant. Success is a fail-closed contract that catches each named mutation while requiring no new tenant input, secret, workflow, or runtime component.

Proposed solution

Extend the existing Platform tenant-envelope runtime and structural contract rather than adding another checkout or CI job. Keep the checks bound to both KRO-generated and manual registration paths, and document the added proof alongside the current envelope gate.

Acceptance criteria

• KRO and manual registrations each retain one tenant-scoped OCIRepository with the expected /manifests URL, semver selector, ghcr-auth secret reference, cosign provider, exact GitHub Actions issuer, and current approved workflow-subject allowlist.
• KRO and manual registrations each retain one ghcr-auth ExternalSecret using the openbao ClusterSecretStore, the infrastructure/ghcr/auth source property, a docker config target owned as kubernetes.io/dockerconfigjson, and the same secret name consumed by the tenant ServiceAccount.
• Both Flux variants and the manual Flux Kustomization reference the matching OCIRepository while preserving the existing tenant impersonation and target-namespace envelope.
• The manual registration inventory contains the ExternalSecret, ServiceAccount, OCIRepository, and Flux Kustomization; the KRO delivery resource identifiers are unique.
• Template cd.yaml remains tag-only and tenant-only, calls the SHA-pinned devantler-tech/actions/.github/workflows/publish-app.yaml, grants only the required contents: read, packages: write, and id-token: write permissions, and derives app-name from the repository name.
• Independent mutations fail for a missing or wrong GHCR source/target/type, either missing secret consumer, a broken Flux source reference, a cross-tenant or widened OCI URL, removed or widened cosign identity verification, missing publish permissions, an unpinned or changed producer workflow, a missing manual inventory entry, and an omitted KRO resource.
• Existing validation remains unconditional, live-main, and fail-closed; README and template-sync ownership guidance stay accurate.

Security and developer experience

Security floor: producer trust cannot widen and private pull credentials cannot silently disconnect without a failing gate. Everyday path: unchanged—this adds validation only, with no new adopter configuration or runtime friction.

Rough size

S — extend the existing envelope validator and its mutation suite.

[coderabbitai]

🔗 Related PRs

#60 - fix(onboarding): rename SecretStore tenant identity [merged]
#94 - test: validate live Platform tenant envelope [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 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:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!