RBAC overview

Activity	Description
Read	Read permissions control object visibility. For example, the Package read permission determines if users can open the Administration > Content > Packages page and view package configurations.
Write	Write permissions control the ability to create, edit, or delete objects. For example the Package write permission determines if users can create, edit, or delete package configurations.
Execute	Execute permissions control the ability to: Run processes, such as initializing endpoints for Tanium™ Patch. Use service accounts, such as the Tanium™ Connect service account. Perform API operations, such as through the Tanium™ Detect API.
Delete	Delete permissions control the ability to delete objects that are beyond the scope of write permissions. For example, the Threat Response Live Connection File delete permission controls the ability to delete a file on an endpoint during a live connection.
Special	Special permissions control the ability to perform activities that are beyond the scope of other permissions. For example, most modules have a Show permission that determines if users can view the module workbench.

The configuration pages for roles, users, user groups, and personas group permissions based on the type of features and configuration objects for which the permissions control access:

Feature or object type	Description
Platform content	Platform content permissions control access to content types that apply across all Tanium modules and that are assigned to content sets. For example, you can assign permissions for sensors, packages, and saved questions in the Default content set.
Module	Module permissions control access to module workbenches, features, and module-specific content (such as Tanium™ Trends data).
Administration	Administration permissions control access to the Administration > Permissions and Administration > Configuration pages of the Tanium Console.
Global	Global permissions control access to activities that are exclusively for reserved roles. For example, only the Administrator reserved role has permission to manage the Tanium license.

For more information, see Provided role permissions and View effective role permissions.

Roles

A role specifies allow permissions for allowed activities or deny permissions for prohibited activities. You assign the roles to users, user groups, and alternative personas to control user access to Tanium features and configuration objects. For details and related procedures, see Managing roles and best practices for Roles.

Content sets

A content set is a group of configuration objects (such as sensors, packages, and saved questions) for which permissions control access at the set level. For example, you can configure a role that applies Sensor read permission to all the sensors in the Base content set. A content set can contain platform content (such as sensors) that applies across all modules or module-specific content (such as Tanium Trends data). You cannot explicitly assign actions to a content set but they effectively belong to the same content set as their associated packages. Tanium provides several predefined content sets through Tanium solutions. You can create a content set to contain custom content or to accommodate changes in the RBAC configuration of your Tanium deployment. You can assign each content object to only one content set. For example, you cannot assign the Domain Name sensor to both the Base and Default content sets, although you can move the sensor from one set to another. A role can apply a permission to multiple content sets. For details and related tasks, see Managing content sets and best practices for Content sets.

Users

A Tanium user configuration associates personas, user groups, computer groups, and roles with a user account. A user can have one or more roles. Users have no permissions other than what their roles provide. A user with no roles can sign in, but is directed to a page indicating insufficient permissions. A user can have one or more computer groups and zero or more user groups. Every user has a default persona and can have zero or more alternative personas. To authenticate users when they access the Tanium Console or API, you can configure a remote authentication service or use the authentication service that is local to the Tanium Server. For details and related tasks, see Managing users and best practices for User permissions.

User groups

A Tanium user group configuration associates personas, computer groups, and roles with a set of users who inherit all the permissions of the user group. A user group can have zero or more users and one or more roles and computer groups. Every user group has a default persona and can have zero or more alternative personas. For details and related tasks, see Managing user groups and best practices for User group permissions.

Computer groups

Tanium users can issue questions and deploy actions only to endpoints that belong to a computer management group that is assigned to users or their user groups. Tanium users use computer filter groups as filters in questions and question results. Users can use only the filter groups that are assigned to a content set that is associated with a role, and the role must be assigned to the users or their user groups. For details and related tasks, see Managing computer groups and best practices for Computer management groups.

Personas

All user accounts have a predefined default persona, which is the persona that applies when users sign in to the Tanium Console. When using the default persona, a user has permissions derived from all the roles and computer groups that are assigned to that persona. The default persona of a user also provides permissions inherited from the default personas of user groups to which the user is assigned. After switching to an alternative persona, the user has only the permissions derived from the roles and computer groups assigned to that persona. For details and related tasks, see Managing personas and best practices for RBAC overview.

RBAC configuration overview

The following figure illustrates the relationships among RBAC components. The arrows indicate how you assign the components to configure user permissions. Note that the roles and computer groups that you assign directly to user groups and user accounts are effectively assigned to the default persona of those user groups and users.

The following steps summarize the workflow for configuring RBAC. The steps also explain how the components interact to define the effective permissions of users when they access the Tanium Console under different personas. The figures in these steps depict two user groups to illustrate the different implications of assigning roles and computer groups to alternative personas and default personas.

1. Configure custom roles. Note that roles with platform content permissions and module permissions apply permissions to content sets. Tanium solutions provide predefined content and content sets. You can also create custom content and content sets.

   The following figure shows an example with one system role that defines module permissions () and three custom roles (, , ).

   

   The next figure illustrates the relationships among content, content sets, and permissions in each example role configuration (roles through in Figure  2).

   

   For details and procedures related to roles, see Managing roles.

2. Define computer management groups.

   

   For details and procedures related to computer groups, see Managing computer groups.

3. Define alternative personas. For each persona, assign roles and computer management groups.

   

   For details and procedures related to personas, see Managing personas.

4. Configure the user groups that you imported from LDAP servers or manually add groups that are local to the Tanium Server. You can assign alternative personas to each user group, and assign roles and computer management groups to the default persona of each user group.

   

   For details and procedures related to user groups, see Managing user groups.

5. Configure the user accounts that you imported from LDAP servers or manually add accounts that are local to the Tanium Server. Assign alternative personas and user groups to each user. You can also assign roles and computer groups to the default persona of each user.

   

   For details and procedures related to users, see Managing users.

6. Sign in to the Tanium Console. For every user, the default persona is active by default and has permissions for all the roles and computer management groups that are directly assigned to the user account or that are inherited from user groups.

   In this example, the RBAC_Administrator role and HQ computer group are assigned to the default persona of the user. The user also inherits permissions from the Monitor role and Europe_Branch computer group that are assigned to the user group Europe.

   

7. When the user switches to an alternative persona for the Tanium Console session, that user has permissions only for the roles and computer management groups that are assigned to that persona.

   In the following figure, the user selects the NAM_Monitor persona that is inherited from the NAM user group.

   

   In the next figure, the user selects the APAC_Trends persona that is assigned to the user account (default persona).

   

The following figure shows the complete workflow to configure the effective permissions of all three personas in this example.

Plan your RBAC implementation

The following are important items and best practices to discuss with your team and Tanium Support (see Contact Tanium Support) when planning the RBAC implementation for your Tanium deployment.

If you plan to import users and user groups from a Lightweight Directory Access Protocol (LDAP) or Active Directory (AD) server, do so before setting up RBAC. For details, see Integrating with LDAP servers.

Naming convention

Before configuring custom roles, content sets, computer groups, and other RBAC objects, devise a naming convention that enables Tanium users to easily determine the purpose for each object and to distinguish it from similar Tanium-provided objects that are imported through Tanium solutions. Distinguishing custom objects is important because it is a best practice to avoid modifying Tanium-provided objects (see Tip 4: Limit customizations to Tanium content). For example, you can use the name of your organization as a prefix in the names of custom objects.

Computer management groups

Identify the sets of endpoints that you want to manage as a group with respect to operations that Tanium users and modules perform. For example, you might configure computer groups based on the geographical organization of your organization, with a group for each region. You can also base computer groups on function (such as data centers and branch offices) or any other criteria.

Computer groups can have overlapping membership. For example, a computer group for all Windows endpoints might include endpoints that are also members of region- or function-based computer groups. Be sure to consider the impact of overlapping membership when configuring and assigning computer groups. For example, you might want users in a security operations center to have management rights to Windows endpoints so that the users can deploy security updates. However, you might not want those users to have management rights for the subset of Windows endpoints that store sensitive financial information.

Base computer group membership on sensor-based filters instead of manually defined lists to enable granular control over which endpoints to include or exclude in the groups.

Content sets

Determine how to organize content set permissions for controlling access to specific data and deploying actions on endpoints. As a best practice, ensure that the content in any particular content set is similar to minimize the risk of assigning unintended permissions to user roles. You can organize content sets based on the following:

• Capability: read or write permissions
• Content type: for example, saved questions, sensors, or packages
• Subject matter: for example, Tanium Client administration or Windows system administration

For content that is provided through Tanium solutions, keep the content objects in their original Tanium-provided content sets. To sustain this practice when moving content between content sets, create copies of Tanium-provided content and move the copies instead of the original versions. Contact Tanium Support before proceeding if you need to move original Tanium-provided content.

Roles

The following are best practices for managing roles:

• Configure custom roles that specify module permissions before configuring roles that specify platform content or administration permissions. Module permissions allow access to a specific module and often provide additional platform content and administration permissions.
• When configuring roles, take advantage of their modularity and cumulative effect on user permissions. For example, instead of creating a role with all the permissions that a particular user needs, and creating another role with only slightly different permissions for another user, create several roles with smaller but unique permissions sets. You can then mix and match these minimalistic roles among various users to achieve the same effective permissions as individual roles that have comprehensive permissions. For details, see View effective role permissions.

Users and user groups

User group permissions

Control permissions at the user group level as much as possible instead of at the user level. Assigning computer groups, roles, personas, and users to user groups minimizes the administrative effort required to update your RBAC configuration. For example, instead of modifying role assignments for the personas of each user who might join or leave your organization, or whose responsibilities might change, you can configure user groups that use sensor-based filters to dynamically adjust group membership when such changes occur.

User permissions

To identify which permissions are needed, consider what each team in your organization needs to accomplish through the Tanium system. In particular, consider the following:

• Which users require access to which Tanium module workbenches and module content?
• Do you want to use the Permission Administrator permission Administrator reserved role to assign full administrator permissions to a few users or assign granular administration permissions that allow or deny page-specific read and write access to the Administration > Configuration pages?

SAML authentication

You can use a Security Assertion Markup Language (SAML) identity provider (IdP) to provide single sign-on authentication for Tanium Console users. For details and related tasks, see Integrating with a SAML IdP.