Roles & access control

TrackMe uses a least-privilege access model: it avoids dangerous Splunk capabilities (such as list_settings or list_storage_passwords) for its everyday operations, and it scopes every user to only the tenants they are entitled to.

The three roles

TrackMe ships three built-in roles, each backed by a Splunk capability:

Role	Capability	What it can do
trackme_user	trackmeuseroperations	Read-only: list entities, view state, read configuration. No edit controls in the UI.
trackme_power	trackmepoweroperations	Manage entities: acknowledge, create / edit / delete entities, edit policies — but not create new content such as trackers.
trackme_admin	trackmeadminoperations	Administer: create tenants and trackers, manage trackers, run schema migrations, manage Configuration Guardian alerts.

Built-in inheritance. trackme_power inherits trackme_user, and trackme_admin inherits trackme_power — so an admin automatically holds power and user capabilities; you do not grant them separately.

Capability elevation. A holder of trackmeadminoperations can create tenants and scheduled trackers even when their native Splunk permissions would not allow creating scheduled objects. This elevation applies only inside TrackMe’s REST context and only within the user’s own capabilities.

How access is enforced

Two independent layers protect every request:

1. Capability check at the REST boundary. Splunk returns 403 if the caller lacks the required capability — the handler never even sees an unauthorised request.

2. Tenant-scope filtering inside the handler. Even with the right capability, a user only sees the tenants whose configured role lists intersect that user’s Splunk roles.

Each tenant lists its admin roles, power roles, and user roles. A user sees or administers a tenant only if one of their Splunk roles appears in the relevant list.

Granting access cleanly

There are two integration patterns:

• Membership — make users members of the built-in TrackMe roles, or

• Inheritance — inherit the TrackMe capability into your own custom roles (recommended for clean, scoped RBAC), then list those custom roles in each tenant’s configuration.

Membership is assigned by the Splunk administrator — directly, or via SSO group mapping.

Warning

The inheritance pitfall — scope your tenants explicitly. By default a new tenant lists all three built-in TrackMe roles in each category. If one of your custom user roles inherits from a built-in TrackMe role, and that built-in role is still listed in a tenant’s RBAC, those users gain access to every tenant left at default. To scope access cleanly, either make the TrackMe capability native to your custom role (instead of inheriting it), or remove the default built-in roles from each tenant’s RBAC configuration.

Remote accounts and the Configuration page

• Remote accounts have their own RBAC. A remote Splunk account restricts which roles may point a tenant at it, preventing data from being sent to an unrelated Splunk. See Integrations & Remote Deployments.

• The Configuration (UCC) page is Splunk-admin territory. It additionally requires the native Splunk capabilities admin_all_objects, list_settings, and list_storage_passwords. A TrackMe tenant admin is not automatically a Splunk admin and cannot reach the Configuration page without them.

Note

When upgrading from an older version, existing tenants’ trackme_admin permissions are automatically mapped onto the newer trackme_power role.

See also

• Roles & access control — in depth — the full capability matrix, a worked multi-team example, and the update_tenant_rbac SPL.

• Creating a tenant — where roles and ownership are first set.

• Managing tenants — updating RBAC and ownership later.

• Integrations & Remote Deployments — remote-account access control.