#+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