Role-based access control (RBAC) enables you to configure granular privileges that control what individual Tanium Console users can see and do with the Tanium Core Platform.
Discuss with your team and your technical account manager (TAM) how you want to use RBAC:
- If you are upgrading from Tanium Core Platform 7.0 or earlier:
- Do you want to keep the existing user role types (such as the Question Author and Sensor Author system user roles) or change the roles to exploit the more granular options available in version 7.1 or later?
- Do you want to preserve existing computer group restrictions, or reconfigure them to exploit the read and write privileges and content-based restrictions available in version 7.1 or later?
For related information and procedures, refer to the KB article Setting up RBAC after upgrading the Tanium Core Platform.
- How do you want to organize content set permissions for controlling access to specific data and actions on managed endpoints? You can organize by:
- Capability: read or write
- Content type: saved questions, sensors, or packages
- Subject matter: Tanium™ Client administration, Windows system administration, and so on
- Do you want to use the Administrator global permission to assign full administrator privileges 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?
- Which users require access to which Tanium™ solution module workbenches?
- Would importing users and user groups from an LDAP server make Tanium user administration easier?
With RBAC, computer group management rights have not changed.
Computer group management rights determine which computers a Tanium user can interact with. RBAC determines which content is available to the user for those interactions.
For more information about computer groups, see Managing computer groups.
With RBAC, you can add further restrictions on the set of questions and actions a user can issue. A fine-grained permissions framework enables you to implement role-based access control models that limit what users and user groups can see and do with Tanium.
Permissions are user abilities: read, write, and execute.
- Content Set permissions determine access to specified sensors, packages, saved questions, dashboards, and categories.
- Micro Admin permissions determine access to the Tanium Console system administration pages.
- Module permissions determine access to Tanium solution module workbenches and features.
- Global permissions determine access rights for the specified activity across all modules—for example, the ability to create and manage content sets.
A content set is a group of sensors, saved questions, dashboards, categories, and packages to which a permission applies. Actions are not explicitly considered content but are treated as belonging to the same content set as the packages from which they were built. You create a content set when the nature of the content requires fine-grained assignment of permissions. For example, you might want to create a content set for Tanium Client maintenance-related sensors and packages so that you can configure roles that grant a wide group of users read access to Tanium Client information but write access to a smaller group. Content can be assigned to only one content set. Many content sets can be included in a role.
A role assigns grant and deny permissions.
- Advanced roles assign fine-grained content set permissions.
- Micro admin roles assign system administration permissions.
- Module roles assign module permissions.
Reserved roles assign privileges that enable special-purpose capabilities. The permissions are implicit, so the roles cannot be modified or deleted.
- The Administrator role grants permission to all content, modules, and administration pages.
- The Content Administrator role grants read/write permission on all content sets, as well as action management privileges.
- The Content Set Administrator role grants read/write permission for the content set and role configurations, including assignment of roles within the user and user group configurations.
- The Deny All role denies access to all content, modules, and administration pages.
A user can be assigned one or more grant or deny roles. A user has no permissions unless granted by a role. A user with no roles can log in, but is directed to an "insufficient permissions" page. A user can be assigned one or more computer groups and zero or more user groups.
A user group configuration can be assigned one or more grant or deny roles, one or more computer Groups, and zero or more users. Users inherit roles and computer groups from the user groups to which they are assigned.
Users can be assigned multiple roles, including both grant roles and deny roles. The system enforces the net effect: all permissions granted or implied, minus those explicitly denied.
In advanced roles, the permission and content set in the deny role must explicitly match the permission and content set in the grant role to effectively strike the grant permission. In this example, the deny Write Sensor permission on Content Set A matches the grant Write Sensor permission on Content Set A, so the grant permission is struck.
In the following example, the deny Write Sensor permission on Content Set D does not match any grant permissions, so it does not have any impact on Erin’s effective permissions.
When assigning content sets to permissions in advanced roles, there is an option to Add all Content Sets that exist or will exist to the permissions. This option is equivalent to listing each and every content set. In this case, the deny Write Sensor permission on Content Set D has effect.
Grant and deny Micro Admin roles follow the same rules as advanced roles. In the following example, Erin is assigned a grant role with specified permissions, and two deny roles with specified permissions. Exact matches are factored out. Erin has all of the capabilities afforded by the grant role assigned to her, minus the capabilities that are specified in the deny roles that are assigned to her.
Module roles do not have deny roles. You can only grant module access. Users who do not have a role that grants module access cannot access the module workbench or functionality.
In grant roles, the write permission implies the read permission. The advanced role assigned to Erin and Grace has the write permission on the specified content sets, so the configuration does not need to specify the read permission. A role that has only the Read Sensor permission on the same content set is created for “read-only” type of users, like Bob in this example.
In deny roles, permissions are not implied. Permissions must be explicitly denied and must exactly match the permission configured in the grant role to be factored out. For example, if a deny role asserts that Write Sensor permission is denied on a specified content set, it does not imply that the Read Sensor permission is denied. When effective permissions are evaluated in the following example, the deny role permissions do not exactly match any grant role permissions, so no grant permissions are struck. The deny role is disregarded, and Bob still has Read Sensor permission on the specified content set.
Users inherit roles from the user groups to which they are assigned. Erin belongs to the user group named David’s Team, so she inherits the permissions that are assigned to that user group. She also has the permissions that are assigned to her user configuration. The system enforces the net effect. In the following example, Erin has all the capabilities afforded by group assignment and user specific grant roles, minus the capabilities that are specified in any deny roles assigned to her.
Reserved roles assign privileges that enable special purpose capabilities. The permissions are implicit, so they cannot be modified or deleted. Reserved roles include:
- Administrator—Full permission to all content, modules, and administration functionality.
- Content Set Administrator—Read/write permission to the roles and content sets configurations, and to the role components of the users and user groups configurations.
- Content Administrator—Read/write permission to all content, as well as action management capabilities.
- Deny All—No access, regardless of any other role that has been assigned to the user.
Special logic applies when a user is assigned a reserved role and other roles.
When a user is assigned the Administrator role, other grant roles are superfluous and deny roles (not including Deny All) are ineffective.
Exception: An advanced role with the Bypass Action Approval permission does have effect when assigned to a user with the Administrator reserved role. The Administrator reserved role does not have this permission by default. Due to the sensitive nature of bypassing approval, this permission must be assigned explicitly in all cases.
The Content Set Administrator role assigns a privilege to read/write the content set and role configurations, including assignment of roles within the user and user group configurations. Any other grant role is ignored. Deny All is the only role that would have effect.
Notice the result when both the Content Set Administrator and Administrator roles are assigned. Only the Content Set Administrator role remains effective. Be careful not to assign the Content Set Administrator role to users who should have other roles. Be careful not to assign (directly or by group inheritance) the Content Set Administrator role to users who are assigned the Administrator role.
The Content Administrator role grants read/write privilege on all content sets, as well as action management privileges. A user can be assigned this reserved role, plus grant module roles and micro admin roles. Any additional advanced roles are disregarded. Grant module roles are added. Micro admin roles are factored.
Users assigned Deny All cannot access anything, regardless of any other role assigned to them, including the Administrator role. In the following example, the only role assigned to Frank that has any effect is Deny All.
Tracking the effect of inherited and implied permissions can get complicated. When you make changes to the configuration, be sure to use the Effective Permissions previews and lists to review the user-specified roles, inherited roles, and net of grant/deny permissions for each Tanium Console user. The details page makes it clear how the effective permissions were derived.
In the roles section, hover over the tile for an inherited role to see the group from which it was inherited. Click the tile for a role to highlight the associated permissions in the permissions sections. Click the All Roles tile to redisplay the permissions without highlighting.
The home page is the page that is displayed when the user initially logs into the console or clicks the logo at the top of a console page. The links on a user's home page are based on the user's effective permissions.
The Tanium Console filters the settings on the user preferences page based on the user's effective permissions. If the user does not have permission to ask questions, many of the preferences are not applicable.
You can import users and user groups from an external Lightweight Directory Access Protocol (LDAP) server. Users and user groups are imported (synchronized) every 5 minutes. The import operation creates or deletes Tanium user configurations and creates, deletes, or modifies members in a group configuration. The LDAP server can be used for authentication for the users that were imported.
The Tanium Console user that is created during installation has privileges like a superuser (like the root or admin user in operating systems). This initial user is configured with the All Groups computer group permission and with the Administrator reserved role, so this user can "do anything" with Tanium. Unlike root and admin, however, this user is not a built-in user. You can modify or delete this user.
The default configuration for a new user has no computer groups, no user groups, and no user roles assigned to it. A user with no roles can log in but cannot access anything. A user must be assigned roles or inherit roles from a user group to have meaningful access.
Last updated: 6/4/2019 4:33 PM | Feedback