Per-widget RBAC

EXAMPLE: Dashboard with widgets gated on different policies:

  WIDGETS ON DASHBOARD          REQUIRES
  ──────────────────────────────────────────────
  Cost trend                    report:view
  Top costly resources          report:view
  Cost saving opportunities     recommendation:view
  Budget health                 budget:view
  Schedule activity             state-history:view
  Upcoming actions              schedule:view

WHAT EACH ROLE SEES:

Viewer, Editor or Admin (system roles):
  All six widgets               shown
  (every system role holds every *:view policy except
   billing:view, so no dashboard widget is gated for them)

Finance Partner (custom role: report:view + budget:view only):
  Cost trend, Top costly        shown
  Cost saving opportunities     placeholder
  Budget health                 shown (the custom role grants it)
  Schedule activity             placeholder
  Upcoming actions              placeholder

DECLARATION:
  Each widget declares one required policy in the widget registry.
  Example: budget_health.requiredPolicy = "budget:view"

RENDERING:
  When the dashboard renders, for each widget:
    if user.has(widget.requiredPolicy):
      render widget normally (fetch data, display)
    else:
      render the "no permission" placeholder in the same slot
      (the widget component never mounts, so it makes no API call)

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 (M4.1.L6).

WIDGET                          REQUIRED POLICY
──────────────────────────────────────────────────────────────────
Key metrics                     report:view
Cost trend                      report:view
Cloud spend breakdown           report:view
Cost reports                    report:view
Top costly resources            report:view
Showback                        report:view
Scheduler success rate          report:view
Cost saving opportunities       recommendation:view
Quick insights                  recommendation:view
Budget health                   budget:view
Schedule execution              state-history:view
Schedule activity               state-history:view
Upcoming actions                schedule:view

┌─────────────────────────────────────────────┐
│  Budget health                               │
│                                              │
│  You don't have permission to view this      │
│  widget.                                     │
│                                              │
└─────────────────────────────────────────────┘

WHY ALWAYS PLACEHOLDER:
  Layout is identical for every viewer of the dashboard
  Two people discussing "the third widget" mean the same one
  Users see what exists and can ask for access to it
  No per-role layout to configure, review or get wrong

IF A WIDGET IS IRRELEVANT TO AN AUDIENCE:
  Don't rely on hiding: build that audience its own dashboard
  without the widget (clone, remove, save; L2)

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

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:
  Role assignment (M4.1.L2-L3): which policies a user holds
  Dashboard composition (L2): which widgets a dashboard carries

ZOPNIGHT-MANAGED:
  The widget registry declares the required policy per widget
  Customers cannot override it (it's a security decision,
  not a customization decision)

DASHBOARD: "Platform Eng Daily" (cloned from the FinOps preset)
WIDGETS:
  1. Key metrics                  (report:view)
  2. Cost trend                   (report:view)
  3. Cost reports                 (report:view)
  4. Budget health                (budget:view)
  5. Top costly resources         (report:view)
  6. Cost saving opportunities    (recommendation:view)
  7. Schedule activity            (state-history:view)
  8. Scheduler success rate       (report:view)

VIEW A: Admin user:
  All 8 widgets shown with data

VIEW B: Viewer (junior, just hired):
  All 8 widgets shown with data
  Cost saving opportunities is read-only: Viewer can see
  recommendations but not act on them

VIEW C: Contractor (custom role: report:view only):
  Widgets 1, 2, 3, 5, 8: shown with data
  Widget 4 (Budget health): placeholder
  Widget 6 (Cost saving opportunities): placeholder
  Widget 7 (Schedule activity): placeholder
  Layout: identical (each placeholder occupies the same slot)

OBSERVATIONS:
  - Same dashboard URL renders differently per role
  - Layout consistent (no shifting widgets per role)
  - The contractor sees that budget, recommendation and schedule
    widgets exist, and can ask for the policies if the work needs them

DASHBOARD reviewed:    __________

WIDGETS on it and the policy each needs (use the table above):
  □ __________ (policy: __________)
  □ __________ (policy: __________)
  □ __________ (policy: __________)

CUSTOM ROLES in your org (Settings → Roles):
  Role: __________  Missing policies: __________
  Widgets that will show a placeholder for it: __________

If you have admin access:
  Ask a user with that custom role to open the dashboard
  Confirm the placeholders match your prediction

FOR EACH placeholder:
  □ Correct (the role should not see it)
  □ Wrong (add the policy to the role, or build the audience
    its own dashboard without the widget)