Per-widget RBAC

EXAMPLE: Dashboard with multiple gated widgets:

  WIDGETS ON DASHBOARD       REQUIRES
  ──────────────────────────────────────────────
  Cost Trend                  report:view
  Top Costly                  resource:view
  Recommendations             recommendation:view
  Audit Log                   audit-log:view
  Budget Health               budget:view
  Showback by Team             report:view

WHAT EACH ROLE SEES:

Junior engineer (Viewer):
  Cost Trend                   shown
  Top Costly                   shown
  Recommendations              shown (view; not apply)
  Audit Log                    placeholder ("Access restricted")
  Budget Health                placeholder
  Showback by Team             shown

Admin:
  All six widgets              all shown

Finance Partner (Viewer + budget-specific custom role):
  Cost Trend, Top Costly        shown
  Recommendations              placeholder
  Audit Log                    placeholder
  Budget Health                shown (their custom role grants this)
  Showback by Team              shown

DECLARATION:
  Each widget declares its required policy in the widget registry.
  Example: AuditLogWidget.requiredPolicy = "audit-log:view"

RENDERING:
  When the dashboard renders, for each widget:
    if user.has(widget.requiredPolicy):
      render widget normally (fetch data, display)
    else:
      render "Access restricted" placeholder
      (no data fetch; no API call; no 403 in logs)

SECURITY:
  The frontend gating decides what to render
  The gateway still enforces: if the user somehow bypasses the
  gate and calls the widget's data API, the gateway rejects.
  Defense in depth (M3.1.L6).

WIDGET                          REQUIRED POLICY
──────────────────────────────────────────────────────────────────
Cost Trend                       report:view
Top Costly Resources             resource:view
Recommendations                  recommendation:view
Schedule Execution               schedule:view
Resource Summary                  resource:view
Anomaly Detection                 anomaly:view (or report:view)
Budget Health                     budget:view (or report:view +
                                  budget context)
Showback by Team                  report:view
Tag Coverage                      report:view
Unit Economics                    report:view
Audit Log                         audit-log:view
                                  (often Admin-only)
RBAC Summary                      role:view (Admin-only)
Cloud Accounts Summary           cloud-account:view
                                  (Admin-only)
Notifications                     notification:view
PAT Inventory                     pat:view (Admin-only)

┌─────────────────────────────────────────────┐
│  Audit Log                                   │
│  ──────────────────────────────────────────  │
│                                              │
│  Access restricted to this widget            │
│                                              │
│  Required:    audit-log:view                  │
│  Your role:   Engineer                       │
│  Current:     no audit-log access              │
│                                              │
│  Contact your admin to request access.       │
│                                              │
└─────────────────────────────────────────────┘

PLACEHOLDER (default):
  Widget visible on layout
  Shows "Access restricted" with the missing policy
  Maintains layout consistency across roles
  Users see what they could access if granted permission

HIDE (optional, customer-configured):
  Widget removed from layout entirely for that role
  Layout collapses around the missing widget
  Cleaner UI for the role
  But: layout shifts between roles can be confusing

WHEN TO HIDE vs PLACEHOLDER:
  HIDE: when the widget is genuinely irrelevant to the role
         (e.g., RBAC Summary on a dashboard mostly viewed by FinOps)
  PLACEHOLDER: when the widget is relevant in principle but the
                user doesn't yet have access
                (e.g., Audit Log on the Engineering dashboard:
                engineers don't have access, but they may want to
                request it for a specific investigation)

FRONTEND PLACEHOLDER:
  UX: don't show empty widgets / 403 errors
  Performance: don't issue API calls that will fail
  Transparency: tell the user what's missing

BACKEND GATEWAY:
  Security: actually enforce that the user can't fetch the data
  Defense in depth: if the frontend has a bug, the gateway still
                    prevents data leak

CUSTOMER CONTROLS:

  1. Role assignment (M3.1.L2-L3)
     Which policies a user has via their role(s)

  2. Per-widget visibility (per dashboard, per role)
     Customer can choose Hide vs Placeholder for any widget
     Configured in dashboard editor → widget settings
     Default: placeholder for all gated widgets

ZOPNIGHT-MANAGED:

  Widget registry declares the required policy
  Customers cannot override the policy (it's a security decision,
  not a customization decision)

DASHBOARD: "Platform Eng Daily" (cloned from FinOps preset)
WIDGETS:
  1. Cost Trend                 (report:view)
  2. Recommendations             (recommendation:view)
  3. Top Costly                  (resource:view)
  4. Schedule Execution          (schedule:view)
  5. Resource Summary             (resource:view)
  6. Audit Log                   (audit-log:view)
  7. Budget Health                (budget:view)

VIEW A: Admin user:
  All 7 widgets shown with data
  Layout: full

VIEW B: Engineer (system Editor role):
  Widgets 1-5: shown with data
  Widget 6 (Audit Log): "Access restricted" placeholder
  Widget 7 (Budget Health): shown with data (budget:view via report:view)
  Layout: full (placeholder occupies same slot)

VIEW C: Viewer (junior, just hired):
  Widget 1 (Cost Trend): shown with data
  Widget 2 (Recommendations): shown read-only (view, no apply)
  Widget 3-5: shown with data
  Widget 6 (Audit Log): placeholder
  Widget 7 (Budget Health): placeholder
  Layout: full

OBSERVATIONS:
  - Same dashboard URL renders differently per role
  - Layout consistent (no shifting widgets per role)
  - Each user sees the same widget set; gated widgets show why
  - New engineer (Viewer) sees the full landscape of what's
    available; can request promotion to Editor for action capabilities

DASHBOARD reviewed:    __________

WIDGETS visible to you:
  □ __________ (shown / placeholder?)
  □ __________ (shown / placeholder?)
  □ __________ (shown / placeholder?)

If you have admin access:
  Open the same dashboard in a private window as a Viewer
  Note which widgets render vs which show placeholder
  Match against the widget-to-policy table

WIDGETS YOU'D WANT TO ACCESS but currently see as placeholders:
  □ __________ (would require policy: __________)
  □ __________ (would require policy: __________)

REQUEST plan:
  Who to contact: __________
  Justification:   __________