94 lines
5.6 KiB
Markdown
94 lines
5.6 KiB
Markdown
# 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
|
|
|
|
1. Start the local platform stack.
|
|
- `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail up -d`
|
|
2. Ensure one platform user has system-panel access, directory visibility, and the new support-access manage capability.
|
|
3. Ensure one workspace owner can manage workspace settings and one workspace operator can view the audit log.
|
|
4. 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
|
|
|
|
1. Open `/system/directory/workspaces/{workspace}` as the authorized platform user.
|
|
2. Confirm the page shows current support-access posture for that workspace.
|
|
3. Request `audit_view` support access with a reason and TTL.
|
|
4. Confirm the page updates immediately to show an active support grant with scope, reason, requester, and expiry.
|
|
5. Open `/system/security/access-logs` and confirm the support-access activation event appears next to platform auth and break-glass history.
|
|
6. End the active support access from the same workspace detail page.
|
|
7. Confirm the active summary disappears and the end event is audited.
|
|
|
|
## Scenario 2: Approve and execute high-risk recovery support
|
|
|
|
1. Open `/system/directory/workspaces/{workspace}` for a workspace that still has an owner.
|
|
2. Request `workspace_recovery` support access with a reason and TTL.
|
|
3. Confirm the request remains pending rather than activating immediately.
|
|
4. Open `/admin/settings/workspace` as a workspace owner.
|
|
5. Confirm the page shows the pending recovery request with requester, scope, reason, and requested TTL.
|
|
6. Approve the request.
|
|
7. Open `/system` and activate break-glass using the existing dashboard action.
|
|
8. Open `/system/repair-workspace-owners` and confirm the recovery page now shows both active recovery support access and active break-glass.
|
|
9. Execute `Emergency: Assign Owner` and confirm the action succeeds only while both prerequisites remain active.
|
|
|
|
## Scenario 3: Exercise the ownerless recovery waiver path
|
|
|
|
1. Use a workspace with zero owners.
|
|
2. Activate break-glass from the system dashboard first.
|
|
3. Request `workspace_recovery` from the system workspace detail page.
|
|
4. Confirm the product requires an explicit ownerless waiver reason rather than pretending approval exists.
|
|
5. Confirm the resulting active grant and recovery audit history clearly indicate the waiver path.
|
|
|
|
## Scenario 4: Inspect and export customer-visible support-access history
|
|
|
|
1. Open `/admin/audit-log` as an authorized workspace operator.
|
|
2. Apply the support-access filter preset.
|
|
3. Confirm the page shows only support-access events for the active workspace.
|
|
4. Export the filtered history.
|
|
5. 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
|
|
|
|
1. Activate `audit_view` only.
|
|
2. Open `/system/repair-workspace-owners`.
|
|
3. Confirm the emergency owner-repair action remains blocked and the page explains that a recovery-scoped support grant is still missing.
|
|
4. Let a recovery-scoped support grant expire while break-glass remains active.
|
|
5. Confirm the recovery page blocks the action again and shows expiry rather than silently relying on break-glass.
|
|
|
|
## RBAC and Plane Semantics Checks
|
|
|
|
1. Attempt to request support access from the admin plane and confirm no platform mutation controls exist there.
|
|
2. Attempt to approve a recovery request from the system plane and confirm that the owner approval surface remains on the workspace settings page only.
|
|
3. Attempt to view or export support-access history from the wrong workspace context and confirm no support state leaks.
|
|
4. Attempt the same actions as an in-scope actor missing the relevant capability and confirm `403` behavior remains distinct from business-state blocking.
|
|
|
|
## Targeted Validation Commands
|
|
|
|
```bash
|
|
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 `OperationRun` or queue family for support access
|