Tanium™ Core Platform 7.1 and later support new methods to support fine-grained role-based access control (RBAC). You can use the RBAC features to manage what Tanium™ Console users can see and do with the Tanium platform.
Discuss with your team and your technical account manager (TAM) how you want to use RBAC:
- Do you want to keep the types of user roles like the system user roles in 7.0 (Question Author, Sensor Author, and so on) or make changes given the more granular options?
- Do you want to continue with the same computer group restrictions, or reconsider them given the availability of read/write privileges and content-based restrictions?
- How do you want to organize content set permissions to control access to specific data or specific actions on client machines? By capability (read, write)? By type of content (saved question, sensor, package)? By subject matter (Tanium™ Client administration, Windows system administration, and so on)?
- Do you want to use the Administrator global permission to grant full administrator privileges to a few users or more granular Micro Admin permissions that grant or deny read and write access to the Administration pages page-by-page?
- Who should have access to which Tanium™ solution module workbenches?
- Would importing users and user groups from an LDAP server make Tanium user administration easier for you?
With RBAC, access control with computer groups has not changed. Restricted computer group management rights remains a key component of Tanium access control. Computer groups limit the scope of the machines for which a user can get results or take actions. When a user asks a question, the question is sent to every Tanium Client; however, the Tanium Client evaluates the question and gives an answer only if the user asking the question has permission to work with the computer group to which the Tanium Client belongs.
You can use computer groups to restrict access based on operating system. For example, a user with the All Computers permission gets results from all computers regardless of operating system. A user with the Windows permission is allowed to get results from Windows computers only.
You can deploy the Custom Tags package to mark sensitivity level to Tanium Clients and create computer groups based on the tags. In this scenario, a user with the All Computers permission gets results from computers regardless of tagging. A user must have the "Top" permission to get results from computers with the Top sensitivity level tag.
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.
In 7.1 and later, the user's home page is based on the user's effective permissions. 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.
In 7.1 and later, 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: 5/16/2018 1:12 PM | Feedback