TenantAtlas/specs/276-support-access-governance/quickstart.md
Ahmed Darrazi 37105653a1
Some checks failed
PR Fast Feedback / fast-feedback (pull_request) Failing after 1m29s
feat(spec-276): implement support access governance — commit all changes
2026-05-05 22:17:14 +02:00

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

  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

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