🤖 Generated by the Agentic Engineer
Evidence
The scaffold's SecretStore authenticates with the renamed tenant role and ServiceAccount, while its ExternalSecret reads apps/<tenant>/config. Platform main separately defines the matching OpenBao policy and Kubernetes-auth role, including the tenant data and metadata prefixes, capabilities, policy attachment, ServiceAccount, and namespace.
The current Platform-envelope gate validates the signed artifact, pull identity, Namespace/RBAC, and Flux relationships, but it never evaluates that OpenBao authorization link. A wrong path, missing capability, or mismatched role identity can therefore leave every scaffold check green and fail only when External Secrets reconciles the adopted tenant.
Audience and impact
Tenant adopters need the first deployment to obtain its application secrets without debugging a late authorization failure. Platform maintainers need drift in this contract to fail before a template change reaches tenants.
Hypothesis and success signal
If scaffold validation binds its renamed secret path and identity to Platform's live OpenBao authorization shape, authorization drift will fail the weekly/PR gate before merge while the normal adoption flow remains unchanged. Success is a valid renamed scaffold passing and representative cross-tenant, widened-path, missing-capability, and mismatched-identity mutations failing.
Proposed direction
Extend the existing Platform tenant-envelope validation rather than adding another workflow. Read the live Platform source already checked out by that job, extract the reference authorization shape, and compare it with the renamed scaffold.
Acceptance criteria
- Require exact tenant-scoped data and metadata prefixes with the expected read and write capabilities.
- Require the Kubernetes-auth role to attach the matching policy and bind the exact tenant ServiceAccount and namespace.
- Bind those values to the renamed scaffold's
SecretStore role and ExternalSecret path.
- Fail closed when the Platform authorization source or any required relationship is missing.
- Cover widened/cross-tenant paths, missing capabilities, and wrong role, policy, ServiceAccount, namespace, scaffold role, and scaffold path with negative controls.
- Exercise the validator from a separate checkout and demonstrate the valid rename path as a user.
Rough size
Small to medium: one existing validator/workflow path plus focused mutation coverage; no production mutation and no new adopter input.
Evidence
The scaffold's
SecretStoreauthenticates with the renamed tenant role and ServiceAccount, while itsExternalSecretreadsapps/<tenant>/config. Platform main separately defines the matching OpenBao policy and Kubernetes-auth role, including the tenant data and metadata prefixes, capabilities, policy attachment, ServiceAccount, and namespace.The current Platform-envelope gate validates the signed artifact, pull identity, Namespace/RBAC, and Flux relationships, but it never evaluates that OpenBao authorization link. A wrong path, missing capability, or mismatched role identity can therefore leave every scaffold check green and fail only when External Secrets reconciles the adopted tenant.
Audience and impact
Tenant adopters need the first deployment to obtain its application secrets without debugging a late authorization failure. Platform maintainers need drift in this contract to fail before a template change reaches tenants.
Hypothesis and success signal
If scaffold validation binds its renamed secret path and identity to Platform's live OpenBao authorization shape, authorization drift will fail the weekly/PR gate before merge while the normal adoption flow remains unchanged. Success is a valid renamed scaffold passing and representative cross-tenant, widened-path, missing-capability, and mismatched-identity mutations failing.
Proposed direction
Extend the existing Platform tenant-envelope validation rather than adding another workflow. Read the live Platform source already checked out by that job, extract the reference authorization shape, and compare it with the renamed scaffold.
Acceptance criteria
SecretStorerole andExternalSecretpath.Rough size
Small to medium: one existing validator/workflow path plus focused mutation coverage; no production mutation and no new adopter input.