We should refactor the permission system to allow better flexibility of both ACL and RBAC.
Roles
Should be able to create roles, and assign multiple user to the same role. A role is essentially a combination of one or more ACLs.
ACL
Should still be able to give users individual access.
There should be tiers of access, and scope that access is granted to. Scope is considered a limiter.
Tiers
- Member
- Owner
- Deploy
- Admin
- Super
Scope
- Global
- Organization
- Application
- Environment
Examples
Role |
Tier |
Scope |
Super Admin |
Super |
Global (Can manage all global configuration) |
Developer |
Deploy |
- Application(abcd) x Environment(xyz)
- Application(abcd) x Environment(staging)
(Can deploy single app to non-prod environments) |
Release Engineer |
Deploy |
Global (Can deploy all apps and environments) |
SRE/Ops |
Deploy |
Environment(prod) (Can deploy all apps to only prod) |
Support Admin |
Admin |
Global (Can manage some global configuration) |
Tech Lead |
Owner |
Organization(efg) (Can create and manage app configuration for all apps in org) |
Considerations
Are tiers inclusive of lower levels? What operations do each grant? Does this differ by scope?
e.g. admin access to environments means different things from admin access to an app.
The operations granted by each scope x tier should be documented.
Is super tier necessary? Is member necessary?
Organizations
There are other things to consider here since we are adding the ability to grant permission to an entire organization. Organizations are currently lightweight and have no meaning. Anyone can add an app to an org, and apps can move freely between them. We should model after github's behavior wrt permission when transferring a repo between orgs.
Self Service
Also keep in mind self service and the ability of application creators/owners to grant others permission.
Maintainability
Can this system be expanded? What if we want to add tiers, or scopes? Are database migrations necessary for this?