Files
org-notes/equinix/design/permissions-migration/permissions-initial-design.org
2024-09-18 12:34:32 -04:00

89 lines
1.8 KiB
Org Mode

#+TITLE: Permissions Redesign
#+AUTHOR: Adam Mohammed
* Overview
This document describes what granularity we'll have available for MVP
when using permissions-api as the policy decision point (PDP).
* Top-Level Resources
** User Based Resources
- User
- APIKeys (bound to user)
** Project Level Resources
- Project (Read/update/delete)
- Instances
- Appliances
- Reservations (aka Hardware Reservations)
- Document
- IP Reservation
- IP Address
- IP Assignment
- Virtual Network
- Virtual Circuit
- Interconnection (Read/update)
- VRF
- Membership
- Invitations
- BGP Sessions
- BGP Configs
- Project API Keys
*** Lower-tier resources
- BGPDynamicNeighbors authorizes through MetalGateway
- ElasticIps authorizes through MetalGateway
- VRFIPReservation authorizes through VRF
- VRFLearnedRoutes authorizes through VRF
- VRFBGPNeighbors authorizes through VRF
- VRFStaticRoutes authorizes Through VRF
- Authorizes through Instance:
- Actions (reboot/power-cycle) (create, list)
- Ip Assignments (create, list only)
- Traffic (index only)
- Termination (POST only)
- BGPSessions (CRUD)
- BGPNeighbors (index only)
- Bandwidth (index only)
- SSH-keys (index only)
- Diagnostics (Read only)
- Metadata (read only)
- Userdata (read only)
- Error reports (create, read)
** Organization Level Resources
- Organization
- Project (create-only)
- Interconnection (create/delete)
** Weird ones
BGP Config Requestss
2FA enforce
* Phase 2
We decided to just throw actions on organizations/projects/user
ok, so I can configure the check access to dump out the context I need.
For every controller + action, I need:
The resource type the permission check is on
The action name that the check requires
With that I can produce the policy that we need on the Permissions API side