Repository navigation
Allow tenant-owned WebApps within their own namespace #4897
Description
🤖 Generated by the Agentic Engineer
Summary
Let a tenant's own deployment artifact use WebApp without gaining authority over another tenant.
Motivation
The invitation-only business portal needs the accepted Tenant/WebApp deployment path. At platform source f3e2a23, the tenant reconciliation role has no WebApp grant; the existing WebApp pilot is platform-controlled. Adding a grant alone is not a complete tenant-ownership boundary.
Proposed Solution
Add the smallest explicit, opt-in tenant WebApp permission and corresponding namespace-bound admission. Preserve existing platform-controlled instances and unchanged omitted-capability behavior. Use the maintained tenant/controller identities and security checks, not a copied workload or broader edit grant. Re-read the current schema and admission contracts before implementation.
Acceptance Criteria
- Document the exact tenant writer, generated-resource namespace and scoped platform-controller exception using current source and runtime metadata.
- Default/omitted capability leaves existing tenant permissions and rendered instances unchanged.
- The enabled tenant can reconcile its own WebApp through the actual signed tenant artifact; missing or foreign namespace targets are rejected by the actual admission path.
- Negative controls cover cross-tenant targets and attempts to obtain broader workload, credential or execution authority. Preserve the existing image, graph-template, namespace and network controls.
- Validate affected renders and security/admission tests, obtain current-head review, settle CI and complete the normal protected platform merge/deployment path. Record permitted live readback separately from static evidence.
- Keep portal identity, private records, payments and worker execution disabled; this permission capability is not a customer release.
Alternatives Considered
A platform-owned pilot can remain supported, but it is not proof that the application's own tenant artifact can reconcile. A blanket grant, copied Deployment or downstream mutation of the graph does not preserve the accepted ownership/security boundary.
Part of devantler-tech/monorepo#3939. Related: platform#4854 (private runtime inputs) and #2523 (stateful workloads), which remain separate implementation concerns.
Priority: High — directly unlocks the requested unified portal deployment. Effort: Medium, including actual admission and deployment proof. Service class: Standard. No implementation has started; no current production fault or approval is inferred.
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Start date
Target date
Effort
Projects
- Status
Activity
devantler commentedon Oct 19, 2026
Implementation refinement from current platform source
bf1b90caddbfa67c8ef6bac6402d4079a376ae98; this is static investigation, not delivered permission or runtime proof.The existing boundary is still absent: the Tenant reconciliation account uses
tenant-edit, which has no WebApp grant, while the WebApp graph derives child namespaces fromspec.name. A bounded foundation can ship inactive before the application deployment:tenant-edit, the Tenant/RGD APIs, credential access, impersonation or execution permissions.Expected authoring surfaces are the Tenant graph and its controller bind grant, a dedicated role and their Kustomize registrations, the new admission policy/fixtures and policy-failure-action census, plus tenant documentation. Graph changes also require a reviewed static-scan baseline update without weakening discovery, placement, image or downstream-mutation controls. Verify omitted-capability render equivalence and enabled least-privilege behavior. Existing PR #5099 overlaps CI and graph-wiring guards, so coordinate those exact files if a new regression needs wiring.
Keep implementation and final runtime verification distinct. Business-site #102 depends on these platform capabilities; its completion cannot also be their prerequisite. Review, merge and deploy the inactive foundation first, then retain the signed-tenant/admission proof as explicit remaining acceptance. Do not close this issue on static tests alone, or activate portal identity, intake, payments or workers.
The separate private-input blocker #4854 also remains real. Its bounded projection must include the runtime's complete file-reading identity, not only UID/GID: current admission otherwise supplies a different fsGroup. Reuse the application's already-merged projection readers; do not add application Secret API permissions or a generic pod-template escape hatch.
chore: agent-claim #4897 nonce=a882025ab8ea7f57534d20df04a57ca1
chore: agent-claim #4897 nonce=acecc492c3133efb32e5f938d29978db
chore: agent-claim #4897 nonce=0fb5f8e3775bb636c24bbd583737b25e
chore: agent-claim #4897 nonce=a6271c35f1ce8ef4651e4ee9de73791f
devantler commentedon Oct 21, 2026
Protected delivery of #5153 is verified: reviewed source
3dc09223412b4e1d297410dc1faa53e023b64902merged ased020a8d5fd0e6d6ca22930be8ca7d8d186638ff. The merge-group run has a complete 23-job inventory with successful production deployment. The post-merge validation has all nine jobs settled successfully or intentionally skipped; its production observer reports convergence to that exact main revision.An independent read-only runtime observation at 2026-10-21T13:19Z matched the deployed artifact to the protected deployment and found its reconciled layers ready. Detailed runtime evidence stays private. The subsequent Go vulnerability scan also passed, including the admission driver and vulnerable negative control; #5164 now carries that recovery receipt.
This issue remains open for an enabled tenant's actual signed artifact to reconcile its own WebApp, plus missing/foreign namespace and broader-authority rejection through the live admission path. Protected deployment and offline engine coverage do not satisfy those remaining acceptance criteria. Portal identity, private records, payments and worker execution remain outside this activation.
devantler commentedon Oct 28, 2026
Recorded the open dependency natively: this issue is now blocked by devantler-tech/business-site#102.
The criteria still open here (the enabled tenant's own signed artifact reconciling its WebApp, plus rejection of missing or foreign namespaces and broader authority through the live admission path) need the signed tenant artifact that business-site#102 publishes. business-site#102 says it does not need this issue closed first, so the link only runs one way. Once #102 publishes a verified artifact, the runtime proof here can run.