5.6 Content Sets, Roles and Personas: Why You Can See What You Can See
Key Takeaways
- Tanium authorisation has three independent parts: the content set grouping objects, the role granting permissions on that content set, and the computer management group granting endpoint access.
- Roles do not control access to computer management groups, so a working setup requires both a role assignment and a separate computer group assignment.
- A saved question, dashboard or category can belong to only one content set, and assigning questions to dashboards does not realign content set permissions for those dependencies.
- Approve Action and Bypass Action Approval are role permissions scoped to specified content sets and can be assigned to personas, users and user groups.
- A persona bundles roles and computer group assignments for a session, so switching persona changes which endpoints answer and which content and approval rights apply.
5.6 Content Sets, Roles and Personas: Why You Can See What You Can See
Quick overview: Content sets and roles are not a published TCO domain, but they decide the answer to almost every "why can't I…?" question an operator asks, and objective NAV-3 routes those questions to Administration > Permissions. Tanium's authorisation model has three independent parts, and a working setup needs all three. Missing any one produces a distinctive failure that is easy to recognise once you know the model.
1. The three-part model
+---------------------------+ +---------------------------+ +---------------------------+
| CONTENT SET | | ROLE | | COMPUTER MANAGEMENT |
| which OBJECTS are | + | which PERMISSIONS on | + | GROUP |
| grouped together | | which content sets | | which ENDPOINTS |
+---------------------------+ +---------------------------+ +---------------------------+
|
v
what this user or persona can actually do
| If this is missing | The symptom |
|---|---|
| The computer management group | You can run the sensor, but no endpoints answer |
| The role permission on the content set | You can see the endpoints, but the sensor or package is unavailable |
| The object is in the wrong content set | Everything looks configured correctly and it still does not work |
Tanium's own worked example makes the point: to let a user see processes running on data-centre endpoints, you must assign a role with Sensor read permission on the content set containing the Running Processes sensor and assign a computer management group containing those endpoints. Neither alone is sufficient.
2. Content sets
A content set is the container that groups Tanium objects — sensors, packages, saved questions, dashboards, categories, filter groups — for the purpose of granting permissions against them.
Key rules:
- A saved question, dashboard or category can belong to only one content set.
- Assigning questions to dashboards, or dashboards to categories, does not automatically realign content set permissions to account for those dependencies. A dashboard can therefore be visible to someone who cannot see one of the questions feeding it.
- The Reserved content set holds objects that cannot be edited, including the reserved computer groups All Computers and No Computers.
- Objects can be moved between content sets — for saved questions, from the Interact Overview page.
[!TIP] When designing content sets, group by who should be allowed to use this, not by what this is about. A content set that mirrors an org chart is usable; one that mirrors a taxonomy of subject matter produces roles with a dozen content set grants each.
3. Roles
A role grants specific permissions on specific content sets. Permissions are granular — read, write and use are separate concerns, and specialised permissions exist for particular operations:
| Permission | What it allows |
|---|---|
Sensor read | Use sensors from the content set in questions |
Saved Question read | See and issue saved questions in the content set |
Filter Group read / write | Use or manage filter groups assigned to the content set |
Approve Action | Approve pending actions associated with packages in the specified content sets |
Bypass Action Approval | Deploy actions on those packages without being subject to approval |
Roles can be assigned to user accounts, personas and user groups. Note the asymmetry established in section 3.4: roles do not control access to computer management groups. Group assignment is a separate act.
The Administrator reserved role is the exception that sees everything, including the Administration > Actions > All Pending Approvals page.
4. Personas
A persona is a named bundle of roles and computer group assignments that a user selects for a session. Its purpose is least privilege in practice rather than in theory: rather than granting one account the union of everything it might ever need, you grant scoped personas and the operator activates the one that matches the task.
| Persona | Roles | Computer groups |
|---|---|---|
| Desktop support | Read sensors, deploy approved desktop packages | Corporate workstations |
| Incident response | Broader sensors, containment packages, Direct Connect | Enterprise fleet |
Switching persona changes which endpoints answer your questions, because results come only from endpoints in computer management groups assigned to the user or persona selected for the current session. It also changes which content you can use and whether you can approve or bypass approvals.
The operational safety argument
Explicit persona switching prevents the highest-consequence class of operator error: running a broad remediation while carrying an unnecessarily wide scope. If the containment action can only reach the endpoints your incident-response persona covers, an accidental deployment is bounded by construction rather than by care.
5. Visibility of saved questions
Saved questions add one more control on top of content set permissions: the Visibility setting.
| Visibility | Effect |
|---|---|
| According to RBAC | Users need Saved Question read permission on the question's content set |
| Only the Owner and Admins can see this object | Only the owner and users with the Administrator reserved role can see it |
By default the creator is the owner, and ownership can be transferred. Which users can even see a saved question's reissue interval additionally depends on the computer groups assigned to them.
6. Diagnosing permission problems
| Symptom | Check, in this order |
|---|---|
| "No endpoints answer" | Active persona, then computer management group assignment |
| "The sensor is not in the list" | Role permission on the content set holding that sensor |
| "I can see the package but cannot deploy it" | Action group scope, then role permissions on the package's content set |
| "My action is stuck" | Require Action Approval — check All Pending Approvals |
| "A colleague cannot see my saved question" | Its content set, then its Visibility setting, then their role |
| "The dashboard renders but one panel is empty" | Content set of the question feeding that panel — dependencies are not realigned automatically |
[!IMPORTANT] Work the model in order — persona, then group, then role, then content set — rather than guessing. Each layer produces a different symptom, so the symptom tells you which layer to inspect.
An operator can issue a question and sees plenty of endpoints, but the sensor they need does not appear in the suggestion list. Which layer of the authorisation model is at fault?
A dashboard renders correctly for a colleague but one of its panels is empty. What is the documented explanation?
Why does Tanium separate personas from user accounts rather than granting each account the union of everything it may ever need?
Which pair of permissions governs two-person integrity for action deployment, and what limits their scope?