Skip to main content

Role-Based Access Control (RBAC)

Table of Contents

Overview

JupiterOne provides a comprehensive role-based access control (RBAC) system that allows administrators to manage user access across the platform. The system is designed to provide granular control over:

  • What data users can access
  • What resources they can manage
  • What features they can use
note

All JupiterOne accounts have access to RBAC features. The system is designed to be flexible enough to support both simple and complex permission requirements.

Components of RBAC

The RBAC system consists of three main components that work together to provide comprehensive access control:

  1. Data Layer RBAC - Controls what data users can access when writing J1QL queries or viewing dashboards
  2. Resource RBAC - Manages CRUD permissions for major resource types (Integrations, Rules, Dashboards)
  3. App Level Permissions - Controls read/write access to application components

Data Layer RBAC

Data Layer RBAC allows administrators to restrict what data users can access when writing J1QL queries or viewing dashboards. This is configured through query policies that filter data based on:

  • Entity class
  • Entity type
  • Integration class
  • Integration type
  • Any other properties that are queryable on an entity
note

Currently, Data Layer RBAC is not enforced within:

  • The Rule feature (specifically rule alert results)
  • The Trend Widgets feature (specifically results shown in trend widgets)
  • The Questions feature

Support for these features is on the roadmap. In the interim, it is recommended to use Resource RBAC to restrict users from creating trend widgets, alert rules, and questions if they should not have access to sensitive data within JupiterOne.

To configure Data Layer RBAC:

  1. Go to Settings (the gear icon) > User Groups
  2. Select the user group you want to edit
  3. In the Query Policy section, select and add the query type and values for each filter and click Add

Configure Data Layer RBAC

Data Layer RBAC Query Policy Configuration

If you want to set up queries based on sets of filters that you want to then link by OR logic, create separate permission sets.

Resource RBAC

Resource RBAC allows administrators to manage CRUD (Create, Read, Update, Delete) permissions for major resource types within JupiterOne:

  • Integrations
  • Rules
  • Dashboards
note

Resource RBAC has no impact on Data Layer RBAC for resource management. For example, if a user has Resource RBAC permissions to manage an integration, they will be able to do so regardless of their Data Layer RBAC settings.

Resource Groups

Resources can be organized into resource groups for easier permission management. A resource group is a collection of resources that logically belong together to meet a specific use case.

Resource Groups

note
  • A resource can only be part of a single resource group
  • Multiple groups can have access to that resource group
  • No Resource Group is not a resource group itself. You cannot give a group access to all resources that do not have a resource group. You can, however, create a resource group called 'General', and assign resources to that group.

Resource RBAC Permissions

You can manage RBAC permissions at the user group level in the settings app. Below are some common use cases:

Resource Group Admin

This group can create, read, update, and delete resources within a single resource group.

Resource Group Admin

Resource Group Readonly

This group can read resources within a single resource group, but cannot create or update resources. This user will have read access to all future resources that are created within this resource group.

Resource Group Readonly

Resource Area Admin

This group can read, update, and delete all resources as well as create resources within any resource group. They can also create resources outside of resource groups.

Resource Area Admin

Granular Resource Access

This is a group that has access to only a few specific resources. This group cannot create resources because only a resource area admin can create resources outside of resource groups.

Granular Resource Access

note

We recommend staying away from granular resource access unless it is very limited in scope. Managing access this way, without resource groups, can become very cumbersome and runs into some system limitations that are set in place.

App Level Permissions

App Level Permissions manage read and write access to application components that do not currently support Resource RBAC. Each app has two permission levels:

  • Read-only - Allows viewing and using the app's features
  • Admin - Allows all actions including administrative functions

App Level Permissions

note

Admin permissions will allow all actions included in the Read-only permissions for each app.

Global Shared Permissions

Some permissions are not bound to a specific app but are relevant to resources that span different apps:

  • Graph Data - Used anywhere entity and relationship data is retrieved on demand or when entities/relationships are mutated directly
  • Questions - Saved J1QL queries used in the Home page Questions Library and in app for mapping to compliance requirements
note

The Graph Data permission does not completely restrict the ability to query graph data. You should limit access to graph data through Data Layer RBAC described above.

App List and Required Permissions

The following apps are available, along with shared permissions that may be used by features in each app:

note

You may see a subset of these apps in your settings based on your account subscription level.

  • Home Page (the base/root page - /home)

    Shared permissions used by this app: Read / Write Questions and Read Graph Data for access to Questions Library and running J1QL queries respectively. Optionally Write Graph Data for editing entities from query results.

  • Assets (URL ending with /assets)

    Shared permissions used by this app: Read / Write Graph Data (app is unusable without Read Graph Data, Write Graph Data used for editing entities).

  • Policies (URL ending with /policies)

    Shared permissions used by this app: Read Graph Data for loading the policy elements and raw data, and Write Graph Data for saving changes to the policy entities.

  • Compliance (URL ending with /compliance)

    Shared permissions used by this app: Read Graph Data for expanding queries used as evidence to view results, Read / Write Questions for editing the questions used in this app.

  • Shared: Graph Data

    Shared permissions used by this app: Read Graph Data. App will not function without this permission as it is focused on graph exploration.

  • Shared: Questions

    Shared permissions used by this app: Questions. This gives users access to the question library in JupiterOne.

Managing User Groups

Creating User Groups

  1. Navigate to the Settings menu (the cog icon next to notifications)
  2. Click on User Groups in the Admin section
  3. From the new window select New Group
  4. Enter the desired Group Name and Group Description, and click Create Group
  5. You will be navigated to the Group's Details page. From here, you can customize:
    • Data Layer RBAC policies
    • Resource RBAC permissions
    • App Level Permissions
  6. Lastly, to add users to the group, navigate to the Group Members tab and select Add Member

Create and edit user groups within JupiterOne

Editing User Groups

  1. Navigate to Settings > User Groups
  2. Select the user group from the menu that you wish to edit
  3. Make your desired changes in the Details and/or Group Members sections
  4. Press Save
note

Changes made to members are saved immediately, only changes made to the user group's details section will need to be manually saved with the Save button. You can also revert accidental changes to a user group by pressing Reset.

Switching User Group Views

Users can be members of multiple groups. You can switch between groups to utilize different permission sets:

  1. Select the profile icon from the JupiterOne dashboard
  2. Choose the group listed under Permission by group

Choosing user permission group in JupiterOne

note

When "All Permissions" is selected, permissions across groups are 'rounded up'. For example, if a user is part of the Administrator group, their edit access from that group would override view permissions in any other group they may be a part of. To swap to the read-only view, they would need to choose a particular group.

Troubleshooting

Common Issues

  1. Users Can't Access Expected Resources

    • Check if the user is in the correct group
    • Verify Data Layer RBAC policies are correctly configured
    • Ensure resource groups are properly assigned
  2. Resource Group Problems

    • Confirm resources are assigned to the correct group
    • Check if resources can only be in one group
    • Verify group access permissions are properly set

Getting Help

If you encounter issues with RBAC configuration consult with your JupiterOne account representative