EPIC: Lagoon RBAC

[Schnitzel]

In order to implement fine-grained, role based authorization in lagoon, we will make architectural changes to the lagoon object model.

Current Lagoon

The current system has two user levels (aka roles): admin and user. If a user is an admin, they have access to everything. If they are not an admin, access is determined by checking if a user is “linked” to a project directly, or via a customer. Any user linked to a project has access to change most aspects of the project.

Proposed Changes

Group

Groups will be added as a new object to lagoon. Groups must be named, may be linked to one or more projects, and may have group members (a set of users and their assigned role). Groups may have one or more sub-groups, which allows for hierarchical organization. Group membership is inherited from parent groups. Groups may be linked to one or more projects. Project links are not inherited from parent groups. Membership roles for a user are combined in the case where multiple groups, or groups via inheritance, reference the same user and are linked to the same project.

Groups are more flexible and will replace the current “customer” object.

User

Users may be members of one or more groups. Users will no longer be assigned directly to projects.
Role
A more flexible and configurable role system will be used. A role is a human friendly identifier, and does not explicitly grant access by itself. Roles must be assigned to a user when they are added to a group.

Explicit role assignment is more flexible and customizable, and will replace the current implicit “admin” and “user” roles.

Project

Projects may be linked to one or more groups. The set of users with access to a project is a combination of all members assigned to all the groups linked to a project. Project resources are protected at the project level.

Environment, Task

Environments and tasks will be split up by environment type, so that the authorization system can differentiate between production and non-production environments. This will allow some functions (ssh/Drush access, more advancedGraphQL mutations etc), to be controlled and restricted by both role and environment. In addition, some dashboard tasks may be restricted to different roles depending on whether the target is a production or non-production environment (e.g. sql-dump, or sql-sync).

Authorization

Authorization checks will use group membership to determine which users have access to a resource (e.g, a project) and what level of access they have. Roles will be configured with a set of allow/deny policies that dictate what parts of Lagoon may be used. The actions a user is allowed to perform on a project (or other resource) is determined by the user’s role(s). The highest level of permissions, given the users set of roles, will be granted.

Technology

The authorization logic will be done with the open source identity and access management software, Keycloak, which is already being used to authenticate users to the UI and Elasticsearch in lagoon. Keycloak has a flexible authorization scheme which allows the configuration of policies that can grant/deny users access to resources via groups and other methods. The flexibility allows lagoon to ship default policies which implement the proposed changes, without blocking future improvements or customizability.

Current Status: https://github.com/amazeeio/lagoon/projects/4