Today we are proud to announce that the highly anticipated RBAC (Role-Based Access Control) is going live. In a few words, RBAC will eventually replace our implicit User Level (Member, Admin, SuperAdmin) permission system and offer a much more granular approach to user permissions. Read on to get the details and the shape of things to come in that department.

If you are a Kentik Administrator in your company who will be tasked with managing user permissions, please take the time to read this KB article which outlines the changes from the Legacy User Level-based system, the new RBAC capabilities, and the gotchas from the migration.

What is RBAC?

Role-Based Access Control is a set of User Permission capabilities that allow Kentik Portal Admins to adopt a granular approach to what actions each user can perform in the Portal.
While RBAC will eventually fully replace our User Level model, both will coexist for a while as we port Portal capabilities from one model to the other (which will take a few quarters).
An additional framework, named Permission Overrides is also in place for a limited number of Portal modules: Connectivity Costs and Synthetic Monitoring. It allowed users to set fine-grain permissions for these aforementioned modules only: this capability has been phased out with this RBAC release and replaced by native RBAC permissions.

How does RBAC work?

Users can access RBAC settings in the company settings menu, as depicted below:

Within this settings screen, RBAC administrators will be allowed to create Roles.
Each Role contains a configurable list of permissions, such as "View Connectivity Costs", and "Edit Synthetic Tests"... and a user can be assigned as many roles as desired. When a user has multiple roles assigned to them, the resulting permissions will be the union of all permissions described in all the assigned roles.

The following screenshot illustrates a role named "Administrators", which contains permissions.

The following screenshot is that of a User Settings (from the User Management screen) displaying which roles and resulting permissions are assigned to a given user. Notice that this user has two roles: "Members" and "Connectivity Costs Viewer"

RBAC uses an "implicit deny" model
It's important to notice that this RBAC permission model is based on "Implicit Deny", which means that there are no "Prevent user from doing this..." type of configuration: a user can only perform an RBAC-regulated action if they have the related permission in any of the roles they have been assigned.

What does the initial release of RBAC encompass? 

The initial goal for this first release is to get rid of the legacy Permission Overrides model, which we are therefore sunsetting. The initial set of Portal areas covered by RBAC are listed below:

• RBAC Management:
  View permission by user, Create Roles, View Roles for the Company, Create Roles, Update Roles, Delete Roles, Assign User to Roles, Remove Users from Roles
• Connectivity Costs:
  View the Connectivity Costs workflow, Configure Providers and Costs
• Synthetic Monitoring Agents:
  Create Agents (Register), View Agents, Update Agents, Delete Agents
• Synthetic Monitoring Tests:
  Create Tests, View Test results, Update Tests configuration, Delete Tests

Introducing Kentik-Managed Roles

For convenience, we have also added the notion of Kentik-Managed Roles: these are roles that are exclusively editable by Kentik. The idea behind these is to provide a simple alternative to cover all existing permissions in one role leveraging Reasonable Defaults.
Whenever a new area of the Kentik Portal is folded into the RBAC engine, reasonable defaults for this area of functionality will be updated to these Kentik-Managed Roles - making it somewhat seamless to our users who are currently satisfied with the User Level model.

There are currently 3 such roles, and they mimic the current Member, Admin, SuperAdmin User Levels. For new users, one of these 3 roles will be by default assigned upon user creation based on the Legacy User Level.

Important Note
By default, the Connectivity Costs workflow is entirely disabled for users with the Member Kentik-Managed Role - as a lot of you have mentioned our permissions around it were too loose. New users created with a 'Member' User Level will require an additional custom Role to access the workflow. Since existing users without permission overrides already had access to the Connectivity Costs workflow, we've added a "Connectivity Costs Viewer" role to their profile so they can keep access to the workflow.

What's next in RBAC world ? 

Our initial RBAC release establishes the foundation of the RBAC permission engine. In the coming quarters we'll build on this foundation by expanding the RBAC model into new areas:

• We are working to extend Labels to multiple areas of the portal beyond Devices, Synthetics Agents, and Synthetics tests (see Test Control Center), and we want to extend RBAC permissioning to apply to content grouped together by users using labels.
• In Q4, we will extend label-based RBAC permissions to Synthetics agents and tests, and will shortly follow with Dashboards and Saved Views, allowing the permissions for content created by users to be managed both centrally and granularly.
• Our soon-to-be-released Credentials Vault will be upgraded shortly with the ability to manage secrets based on labels.

More than anything, we would love to hear your thoughts on which area of Kentik Portal you would like us to work on implementing next, so please do let us know!