As you've read in previous updates, we are progressively extending our RBAC capabilities towards an increasing number of Kentik Portal functionalities. This time around, we've added RBAC to Devices.
Read on as we explain how this works!

Previously on RBAC...

1. In November 2023, we released our initial RBAC capabilities, you can read about it here: https://new.kentik.com/role-based-access-control-is-live-3R1D68. The initial release covered RBAC management, Connectivity Costs, Synthetic Monitoring Agents and Synthetic Monitoring tests.
2. In March 2024, we both overhauled the admin UI for RBAC, and Label-based RBAC, extending its capabilities to dashboards and saved views based on Labels: https://new.kentik.com/label-based-rbac-and-more-2GBruo, so users could manage content in a centralized and more straightforward way. 
3. In May 2024, we extended RBAC capabilities to our Credentials Vault: https://new.kentik.com/rbac-extends-to-credentials-vault-1Yrrwc.
4. In November 2024, we linked SSO and RBAC. We introduced Role-Sets and SSO to RBAC attribute mapping, so that user groups read from your SSO Identity Provider could dictate and enforce RBAC permissions for groups of users.
   https://new.kentik.com/sso-to-rbac-attribute-mapping-30lFi8.

As we've said before, the entire migration of our legacy UserLevel model (Member, Admin, SuperAdmin) into RBAC is going to take some time, but we're constantly adding to its coverage.

What does RBAC for Devices look like ?

In your RBAC Role creation UI, you can now see this additional area of permissions, allowing you to enable permissions throughout the portal related to Devices exporting telemetry to Kentik.

With the unification of NMS and Flow management screens released in February 2025, these Device-level permissions apply to both NMS and Flow devices, see the announcement here: https://new.kentik.com/nms-flow-unified-device-experience-makes-them-better-together-2xzqg.

When configuring RBAC permissions around devices, the View, Update, and Delete permissions can be scoped to specific labels. For instance, if a certain team should only have View access to edge and core devices, your permission set should look like this:

Effectively, this means that users assigned to this role — assuming no other assigned role grants broader access (since we union permissions across all roles) — will only be able to see devices with the edge and core labels,  which, among other things, imply:

• Any Dashboard or Saved view they will access will only include data from devices with these two labels, even if the dashboard or saved view initially contains All Devices
• When on the unified Device Management screen, these users will only see core and edge devices listed, even if there are more of them
• Users will only be able to see the interfaces in the Settings > Interfaces screen corresponding to the devices that they have permissions to view (therefore the same Interface screen will contain more interfaces for device-unrestricted users than one with restrictions)
• For any Network Explorer view that contains device breakdowns, those of a user with device restrictions will only include data from those devices (therefore the same screen will look different from that of a user with permissions to all devices)
• Any Device API call will be bound to the same permissions as that of the user whose API token is issued to make the API call: in other words, API and Portal permissions for devices are the same for a given user
• The Capacity Planning workflow will exclusively use the permissions of a given user to display capacity: if a capacity group contains interfaces from devices a user isn't allowed to see, they won't be displayed in the Capacity Group details (again the same screen will look different depending on the Device Permissions of the user)

As an exception, Connectivity Costs is unaffected by Device RBAC for now. Users will be able to see all connectivity costs, including for interfaces that belong to devices they are not permitted to view. If they click on these interfaces, then they will be blocked from accessing further details for that device.

How do UserLevels map to Device RBAC permissions?

Prior to Device RBAC rollout, device permissions where somewhat rudimentary:

• Member users could only View devices
• Admin users could View, Create, Update, Delete devices
• SuperAdmin users had the same permissions as Admins

For the sake of backwards compatibility, the Member, Admin and SuperAdmin Kentik-Managed Roles have been updated accordingly

Admin, SuperAdmin Kentik-Managed Role

Member Kentik-Managed Role

When a more fine-grain approach is needed, Kentik-Managed Roles can be removed from users and replaced with more elaborate ones. For now, Kentik-Managed Roles are intended to provide continuity between UserLevels and RBAC.

Please note:

A user with Device Create permissions can create a device with any label they want. If they only have Device View access to a restricted set of device labels, this means that not assigning a label at device creation time, or assigning one they can't View devices for, will prevent them from being able to see the device.
We will be remedying this in a short term update where any Create permission will be able to come with a default set of allowed labels, together with making labels mandatory (showing only the ones a user has access to) at Device Creation time.

What's next ?

Based on your feedback, our next RBAC extensions will be:

• "Add" type permissions to be label-compatible:
  • Configure which labels a user is allowed to attribute to a device at creation time
  • Make label assignment mandatory for users with Label-based permissions to avoid cases where users create devices they can't eventually access because of label-restricted permissions.
• MyKentik Portal RBAC: leverage labels to determine which user has create/edit/delete access to which Tenants

If there are different areas of Kentik Portal that you'd like to see rolled-up into our RBAC capabilities, please let us know !