1.8 KiB
1.8 KiB
Permissions Redesign
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