5.6 KiB
5.6 KiB
Quickstart: Enterprise Access Boundary & Support Access Governance v1
Date: 2026-05-05
Branch: 276-support-access-governance
This quickstart is the intended reviewer flow after implementation. It stays bounded to workspace-scoped support access, recovery approval, support history, and break-glass separation.
Prerequisites
- Start the local platform stack.
export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail up -d
- Ensure one platform user has system-panel access, directory visibility, and the new support-access manage capability.
- Ensure one workspace owner can manage workspace settings and one workspace operator can view the audit log.
- Seed or factory-create:
- one workspace with at least one owner
- one ownerless workspace for the waiver scenario
- one platform tenant row for current system audit logging
- one platform user who will request support access
Scenario 1: Request and end low-risk support access from the system workspace detail page
- Open
/system/directory/workspaces/{workspace}as the authorized platform user. - Confirm the page shows current support-access posture for that workspace.
- Request
audit_viewsupport access with a reason and TTL. - Confirm the page updates immediately to show an active support grant with scope, reason, requester, and expiry.
- Open
/system/security/access-logsand confirm the support-access activation event appears next to platform auth and break-glass history. - End the active support access from the same workspace detail page.
- Confirm the active summary disappears and the end event is audited.
Scenario 2: Approve and execute high-risk recovery support
- Open
/system/directory/workspaces/{workspace}for a workspace that still has an owner. - Request
workspace_recoverysupport access with a reason and TTL. - Confirm the request remains pending rather than activating immediately.
- Open
/admin/settings/workspaceas a workspace owner. - Confirm the page shows the pending recovery request with requester, scope, reason, and requested TTL.
- Approve the request.
- Open
/systemand activate break-glass using the existing dashboard action. - Open
/system/repair-workspace-ownersand confirm the recovery page now shows both active recovery support access and active break-glass. - Execute
Emergency: Assign Ownerand confirm the action succeeds only while both prerequisites remain active.
Scenario 3: Exercise the ownerless recovery waiver path
- Use a workspace with zero owners.
- Activate break-glass from the system dashboard first.
- Request
workspace_recoveryfrom the system workspace detail page. - Confirm the product requires an explicit ownerless waiver reason rather than pretending approval exists.
- Confirm the resulting active grant and recovery audit history clearly indicate the waiver path.
Scenario 4: Inspect and export customer-visible support-access history
- Open
/admin/audit-logas an authorized workspace operator. - Apply the support-access filter preset.
- Confirm the page shows only support-access events for the active workspace.
- Export the filtered history.
- Confirm the export contains request, approval, denial, activation, expiry, end, and waiver events for the current workspace only.
Scenario 5: Preserve support-access and break-glass separation
- Activate
audit_viewonly. - Open
/system/repair-workspace-owners. - Confirm the emergency owner-repair action remains blocked and the page explains that a recovery-scoped support grant is still missing.
- Let a recovery-scoped support grant expire while break-glass remains active.
- Confirm the recovery page blocks the action again and shows expiry rather than silently relying on break-glass.
RBAC and Plane Semantics Checks
- Attempt to request support access from the admin plane and confirm no platform mutation controls exist there.
- Attempt to approve a recovery request from the system plane and confirm that the owner approval surface remains on the workspace settings page only.
- Attempt to view or export support-access history from the wrong workspace context and confirm no support state leaks.
- Attempt the same actions as an in-scope actor missing the relevant capability and confirm
403behavior remains distinct from business-state blocking.
Targeted Validation Commands
export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/System/SupportAccessGrantResolverTest.php
export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/System/SupportAccessRequestFlowTest.php tests/Feature/System/SupportAccessRecoveryBoundaryTest.php tests/Feature/Auth/BreakGlassModeTest.php tests/Feature/Auth/BreakGlassWorkspaceOwnerRecoveryTest.php tests/Feature/System/Spec114/AccessLogsTest.php
export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/Settings/WorkspaceSupportAccessApprovalTest.php tests/Feature/Monitoring/AuditLogSupportAccessHistoryTest.php
export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent
Out of Scope Confirmations
While validating this slice, confirm that the implementation does not add or imply:
- unrestricted admin-plane delegated support browsing
- customer-user impersonation or session takeover
- SCIM or broader SSO expansion
- a second support console or history page
- a new
OperationRunor queue family for support access