RBAC Structure

Role Based Access Control (RBAC) definitively grants permissions to accounts in a positive, additive way.

This page describes the construction of a role from granular permissions applied to scopes, grouped into policies.

Structure and examples

RBAC can become complex, so it's good to have a firm understanding of the structure involved. Here's a walkthrough with an example.

A short-sighted way of managing permissions would be to allow any permissions to be assigned directly to any user. This might work for very small groups of users, permissions, and projects, but it would soon become unmanageable.

Instead, Hydrolix provides roles and policies to help group users and permissions. Policies depend on scope information to help assign a group of permissions to the correct policy.

Imagine a user named Tessa who should have read access to the tables in a project named "Balloons." Tessa, who is able to read all the tables in the Balloons project, is a member of the ProjectReader role. That role has a policy that allows the read_table permission for all the tables in the Balloons project. Following the same structure as the image above:

Later, Tessa can be assigned more complicated roles by simply assigning roles to her, rather than giving her each permission related to a scope via a jumble of policies. For instance, if Tessa were later granted permissions to edit color dictionary in the database, she could simply be granted the ColorsEditor role. This assigns four permissions within the scope of the Colors dictionary. This configuration is pre-defined so it can be quickly assigned to other users as well.

Subsequently, if anybody in the ColorsEditor role needs additional permissions, additional policies can be added to the ColorsEditor role. For instance, if Tessa and all the other people in the ColorsEditor role needed permissions to edit a "Hues" dictionary, a policy similar to the one above for the Colors dictionary could be added to the ColorsEditor role.