Currently, the DataRobot platform allows administrators to set up and manage users and their access at an organization, group, or individual user level. As of DataRobot Release 6.2, both Managed AI Cloud and On-Premise users have access to role-based access controls (RBAC) to help further manage user permissions and access within the platform.
RBAC offers a variety of benefits for an organizational admin, including the ability to quickly set up varying levels of access to different parts of the DataRobot platform. In this article, we will examine some best practices and design considerations for setting up organizations and groups and explain how you can integrate DataRobot’s RBAC functionality into your user administration designs.
Overview
Previously, when an administrator wanted to limit access to certain areas of the DataRobot platform to specific groups of users, they could either give a user full access to that area or no access at all. The only granularity that existed was at the project level where a user could explicitly share a project with another user with varying degrees of access. With RBAC controls in place, a user administrator can specify if a group of users has read, write, admin, or no access to specified parts of the DataRobot platform.
It is important to note that while a user still retains the ability to share projects with other users, if they have read-only access to projects (as defined by an applied RBAC role) and are given access to a project with full admin privileges, the RBAC role limitations take precedence. This means they will be limited to read-only access to that project.
Prerequisites
Our focus for this article is on-premise installations of DataRobot Release 6.2 or later. Your administration user needs the "Can manage users permission" enabled for their account in order to configure and manage RBAC controls.
Design Considerations
Organizations
You can select an organization and then view or modify its settingsm such as the groups and user members, number of workers, sharing policy, permissions, default RBCA role, etc.
You may need only a single organization: If you do not need to worry about splitting resources and you do not need to limit access to things like projects and deployments amongst different teams, then you should be fine with just creating a single organization within DataRobt.
The organization settings define the base level of access for a user. Make sure that any default RBAC role and features that you want to enable should be accessible to all users in the organization. For example, if you want all users to be able to export Scoring Code and DataRobot Prime versions of models, or have access to extra data integration options like KDB+ or Qlik, then you enable those permissions for the organization.
Please note that if you give a group a more restrictive role than what is explicitly set at the organization level, the more expansive organization role privileges will override the group restrictions. Additionally, If you want to give a subset of users access to a specific feature, then you will want to set that option at the group level instead of the organization level.
Groups
With a baseline of enabled features and a default RBAC role defined at the organization level, it’s time to look at how to construct the different groups for your organization's users.
First we consider the types of groups we want to use, based on the user types that will interact with the platform. In general, we want to create groups for users that fall into three buckets; administrators, general users, and read-only users.
- Administrator group, as the name implies, would have total access to specific parts of the DataRobot platform to perform any task on that object. This would include the ability to deploy models developed by data scientists into production on the platform.
- General user groups are used to ensure that users have proper access to specific parts of the platform to do their work, such as model building and data analysis.
- Read-only groups would be used for managing and assigning very limited access. Accounts that are designed to be used by other systems to interact with DataRobot, or users that just need insight into work being done on the platform and are not actually performing any tasks, would be included in read-only groups. A common example is a service account used for making scoring requests against deployed models.
Next, we look at the corresponding RBAC roles for a group. Currently, a single organization or group can have only one assigned role. (Although a user can be directly assigned a default role, that is not the recommended practice. We'll explain when we get to the user level.)
You should create a group for each RBAC role that is available in DataRobot. This will enable you to give specific multiple roles, as needed. For example, if you want a user to have both Apps Admin and MLOps Admin roles, then they need to be members of the two groups that have those role settings.
It is important to keep in mind that access to features and RBAC roles are cumulative. In other words, if a user is a member of multiple groups, they gain access to all the features enabled in those groups, along with the most permissive version of roles if the groups have potentially conflicting role assignments.
Users
DataRobot allows you to assign access to features and a default RBAC role, assuming that access to a feature has not been explicitly defined at the organization or group level.
However, you should avoid making one-off changes to specific users. Directly assigning a specific RBAC role or access to a feature to a user adds additional complexity to user management: you may have to modify many users rather than only a few groups. Additionally, it increases the possibility of having users with non-standardized levels of access. Instead, ensure that the features and RBAC roles that a specific user needs to complete their work are properly defined at the organization and group levels, and that the user is a member of those groups.
Example RBAC Setup
The table below outlines the recommended organization and associated groups for the DataRobot platform. Creating this structure will ensure that access to all RBAC roles is available and that access to certain groups of features, like user administration and general platform administration, is fully defined. Most groups will only be used to define a default RBAC role, while some will only be used to enable feature flags related to user administration and platform administration. The example charts (below the table) demonstrate how this would look in practice.
You would make these changes within the Permissions tab of the organization or group that you are currently editing.
Model deployment access note
It is important to recognize that the deployment of models is considered an administrator-level task within DataRobot. This means that a general user group, like the one listed in the example below, by default does not have the ability to deploy models. If you want your users to also be able to deploy models, then make them members of the MLOps Administrators group, which has the MLOps Admin default role.
Example setup for organizations
- Default role: none
- Products and features: Enable any products or features that you want all users in the organizations to have (Scoring Code, integration options, extra blueprints, etc.)
Example setup for groups
Administrators
- Apps administrators
- Default role: Apps Admin
- Data administrators
- Default role: Data Admin
- MLOps administrators
- Default role: MLOps Admin
- Products and features: “Enable Global Approval Workflow”
- Project administrators
- Default role: Project Admin
- User administrators
- Default role: none
- Products and features: “Can manage users” and “Enable SAML SSO configuration management”
- Platform administrators:
- Default role: none
- Products and features: All admin settings that are available
General users
- General User*
- Default role: Data Scientist
- Products and features: Enable any products or features that you want general users to have access to, but do not want all users to access
(* remember that this group does not have access to deploy models)
Read-only users
- Predictions only
- Default role: Prediction Only
- Read only
- Default role: Viewer
Putting It Together
Using the suggested groups and organization settings shown above, we created example diagrams of how an administrator, user, and predictions-only service account would be set up within an organization to have access to specific parts of the DataRobot platform.
Example apps and MLOps deployment administrator setup
Example user setup
Example predictions-only service account setup
Final Thoughts
This article introduced DataRobot's role-based access controls, provided suggestions for laying out group and organization permissions and access, and presented many best practices. When combined with these best practices, RBAC will help you set up enterprise-level access controls for user administration, resulting in even better platform management.
If you have questions about what I presented here or want more details or explanation, please let me know - PM @stretch. I look forward to hearing from you!
More information
If you're a licensed DataRobot user, you can find more information for RBAC settings in the in-app Platform Documentation: https://<your_datarobot_instance_name>/docs/admin/reference/rbac-ref.html.
