RBAC overview

Tanium RBAC implementation and concepts

Role-based access control (RBAC) enables you to configure granular permissions that control what individual Tanium Console users can see and do with the Tanium Core Platform, and which endpoints they can monitor and manage. The permissions derive from roles and computer groups that are assigned to user accounts and that users inherit from user groups. The Tanium implementation of RBAC involves the following key concepts and configuration objects. Figure  1 and Figure  2 illustrate how the configuration objects interact to determine the effective permissions of users.

Permissions

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, 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 for specified activities across all modules, such as the ability to create and manage content sets.

For more information, see Implied role permissions and Effective role permissions.

Roles

A role assigns grant permissions to specify allowed activities, or deny permissions to specify prohibited activities. You can assign the following types of roles to users and user groups:

  • Advanced roles assign content set permissions.
  • Micro admin roles assign Tanium system administration permissions.
  • Module roles (grant only) assign Tanium solution module permissions.
  • Reserved roles assign permissions that enable special-purpose capabilities that other roles cannot control, such as managing action groups.

For related tasks and details, see Managing roles.

Content sets

A content set is a group of plugins, sensors, saved questions, dashboards, categories, and packages for which permissions control access. Actions are not explicitly considered content but are treated as belonging to the same content set as the packages from which they were built. Tanium provides several predefined content sets through Initial Content packages and Tanium solution modules. 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 content to only one content set. A role can specify permissions for multiple content sets. For details and related tasks, see Managing content sets.

Users

A Tanium user configuration associates user groups, computer groups, and roles with a user account. A user can have one or more grant and deny roles. Users have no permissions other than what their roles provide. A user with no roles can log in, but is directed to a page indicating insufficient permissions. You can assign one or more computer groups and zero or more user groups to a user. For details and related tasks, see Default user and Managing users.

User groups

A Tanium user group configuration associates computer groups and roles with a set of users who inherit all the permissions of the group. A user group can have one or more grant and deny roles, one or more computer groups, and zero or more users. For details and related tasks, see Managing user groups.

Computer groups

Computer group management rights determine which endpoints a Tanium user can interact with. Roles do not control access to computer groups, but roles do control which content is available to the user for interacting with endpoints. For details and related tasks, see Managing computer groups.

The introduction of RBAC in Tanium Core Platform 7.1 did not change computer group management rights.

The following figure shows an example of how RBAC components are assigned and interact to determine user permissions.

Figure  1:  Roles, computer groups, users, and user groups

The following steps summarize the workflow for configuring users, and correspond to the numbers in Figure  1:

  1. Define advanced roles, module roles, and micro admin roles (not shown in the preceding figure). Figure  2 illustrates the relationships among content, content sets, and permissions in each role configuration (roles A to C, in this example).
  2. Define computer groups.
  3. Define user groups, and assign one or more roles and computer groups to each user group.
  4. Define users, and assign one or more user groups, roles, and computer groups to each user.

The following figure shows the configurations of roles A to C in Figure  1:

Figure  2:  Content, content sets, permissions, and roles

The following steps summarize the workflow for configuring roles and correspond to the numbers in the preceding figure:

  1. Optionally, define any custom content that you need and assign it to content sets. You can also create custom content sets. Tanium content packs and solution modules provide predefined content and content sets.
  2. Define advanced roles, module roles, and micro admin roles (not shown in the preceding figure). A role can specify multiple permissions for multiple content sets. Assign one or more roles to each user group and user.

Plan your RBAC implementation

The following are important items and best practices to discuss with your team and Tanium Technical Account Manager (TAM) when planning the RBAC implementation for your Tanium deployment.

Upgrades

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.

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 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 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. Defining computer group membership through sensor-based filters instead of static lists is a best practice, and enables 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
  • 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. As much as possible when moving content between content sets, create copies of Tanium-provided content and move the copies instead of the original versions. If moving original Tanium-provided content becomes necessary, consult your TAM before proceeding.

Roles

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.

Avoid modifying 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.

Users and user groups

LDAP support

If you plan to import users and user groups from a Lightweight Directory Access Protocol (LDAP) or Active Directory (AD) server, do so before assigning roles. The Tanium Server automatically synchronizes with the LDAP server every five minutes, and you can manually synchronize at any time. The synchronization updates the Tanium Server with any changes that occurred on the LDAP server, including any new or deleted users, new or deleted user groups, and changes to user group membership. Optionally, you can use an LDAP server to authenticate the imported users. For details and related tasks, see Integrating with LDAP servers.

User group permissions

The best practice is to control permissions at the user group level as much as possible instead of at the user level. Assigning roles and users to user groups minimizes the administrative effort required to update your RBAC configuration. For example, instead of modifying role assignments for 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?
  • 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?

SAML authentication

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

Last updated: 7/30/2019 3:03 PM | Feedback