Role-based access control (RBAC) enables you to configure granular permissions that control what individual Tanium Console and API users can see and do with the Tanium Core Platform, and which endpoints they can monitor and manage. The permissions derive from
Permissions define the read, write, and execute activities that a user or user group is allowed to perform in the Tanium Core Platform.
- Content Set permissions determine access to specified plugins
, filter groups, sensors, packages, saved questions, dashboards, and categories.
- Micro admin permissions determine access to the system administration pages of the Tanium Console.
- Module permissions determine access to Tanium solution module workbenches and features.
- Global permissions determine access rights to specified activities across all modules, such as the ability to create and manage content sets.
A role specifies grant permissions for allowed activities or deny permissions for prohibited activities. You can assign the following types of roles to
- Advanced roles assign content set permissions.
- Micro admin roles assign Tanium system administration permissions.
- Module roles (grant only) assign Tanium solution module permissions
and module-specific content set permissions.
- Reserved roles assign permissions that enable special-purpose capabilities that other roles cannot control, such as customizing the Tanium Console.
For related tasks and details, see Managing roles.
A content set is a group of configuration objects, including plugins, sensors, packages
A Tanium user configuration associates
A Tanium user group configuration associates
All user accounts have a predefined default persona, which is the persona that applies when users log into 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.
The following figure illustrates the relationships among these RBAC components. The arrows indicate how you assign the components to configure user permissions.
RBAC configuration overview
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.
Before starting this workflow, review the important details and best practices described under Plan your RBAC implementation.
If you plan to import users and user groups from an LDAP or AD server, configure the imports before configuring RBAC (see Integrating with LDAP servers).
Define roles. Note that advanced roles and module roles apply permissions to content sets. Tanium content packs and solution modules provide predefined content and content sets. You can also create custom content and content sets.
The following figure shows an example with two advanced roles (A and D), a module role (B), and a micro admin role (C).
The next figure illustrates the relationships among content, content sets, and permissions in each example role configuration (roles A to D in Figure 2).
For details and procedures related to roles, see Managing roles.
Define computer management groups.
For details and procedures related to computer groups, see Managing computer groups.
Define alternative personas. For each persona, assign roles and computer management groups.
For details and procedures related to personas, see Managing personas.
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.
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.
Log into 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.
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.
The following are important items and best practices to discuss with your team and Technical Account Manager (TAM) 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.
If you are upgrading from Tanium Core Platform 7.0 or earlier, see the KB article Setting up RBAC after upgrading the Tanium Core Platform.
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 modules and content packs. 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), operating system (Windows, macOS, and Linux), 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.
Basing computer group membership on sensor-based filters instead of manually defined lists is a best practice, and enables granular control over which endpoints to include or exclude in the groups.
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
- 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 modules and content packs, the best practice is to 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. If you need to move original Tanium-provided content, consult your TAM before proceeding.
The following are best practices for managing roles:
- Configure module roles before advanced or micro admin roles. Module permissions grant access to a specific module and often provide additional advanced and micro admin 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 Effective role permissions.
Do not modify Tanium-provided module roles. The process of upgrading or re-importing a module overwrites the module role configurations, along with any modifications that you made.
You can reassign alternative personas among multiple users and user groups, whereas each default persona is unique to a single user or group and you cannot reassign it. Therefore, the best practice for modularizing permissions is to assign roles and computer groups to alternative personas instead of default personas. This practice simplifies updating your RBAC implementation when necessary, such as when users leave or join your organization, or when they move between user groups.
Users and user groups
If you plan to import users and user groups from a Lightweight Directory Access Protocol (LDAP) or Active Directory (AD) server, set up the imports before you perform other RBAC tasks. The Tanium Server automatically synchronizes with the LDAP server every five minutes
User group permissions
Control permissions at the user group level as much as possible instead of at the user level. Assigning computer groups, roles,
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 Administrator global permission to assign full administrator permissions to a few users or assign granular micro admin permissions that grant or deny page-specific read and write access to the Tanium Console Administration pages?
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.
Last updated: 4/2/2020 6:26 PM | Feedback