Role Based Access Control and ownership

Least privileges approach

  • Since the release version 2.0.34, TrackMe uses a strict least privileges approach which avoids any requirements for dangerous or problematic Splunk capabilities, such as list_settings or list_storage_passwords

  • TrackMe uses a 3 RBAC levels schema, with the following builtin roles: trackme_user, trackme_power, trackme_admin

  • Each of these roles provide a builtin capability which allows accessing to the associated REST API endpoints

  • Depending on the level of privileges, users will have access to different parts of TrackMe user interfaces, for instance a read only user will not have visibility against any administration related shortcuts or entity edition buttons

  • When migrating from a prior version, TrackMe will automatically assign the same permissions for existing tenants for the trackme_admin roles of the tenants to the trackme_power roles

  • You can use TrackMe’s builtin RBAC re-assignment to update a tenant configuration according to your needs

  • RBAC is also supported and required at the level of Splunk remote account

  • Roles inheritance for TrackMe Virtual Tenants and Remote accounts is supported from version 2.0.61

About role inheritance

  • Roles inheritance for TrackMe Virtual Tenants and Remote accounts is supported from version 2.0.61

  • From this version, you can use direct membership or inheritance for all RBAC dimensions in TrackMe

Introduction to RBAC in TrackMe

Role Based Access Control and Ownership management are supported and taken in charge natively, relying on a strict implementation of Splunk capabilities.

In short:

  • When a Virtual Tenant is created, TrackMe administrators can define target indexes for every type of data generated by TracKme

  • Access to these indexes can be granted via Splunk Role Based Access Control

  • The Virtual Tenant knowledge objects permissions are configured during the creation, allowing two types of accesses, admnistrative accesses and user accesses

  • When new knowledge objects are created for the tenant via TrackMe, the permission rules defined for the Virtual Tenants are applied automatically against these new objects

  • At any time, a TrackMe administrator can update the Role Based Access Control permissions for the Virtual Tenant, the tenant configuration will be updated and all existing knowledge objects for the tenant will be updated automatically

TrackMe builtin roles capability matrix

The following table summarizes TrackMe’s builtin roles, associates capabilities, endpoints accesses and privileges categories:

TrackMe builtin Roles and Capabilities

Role

Capability

Endpoints root

Description

trackme_user

trackmeuseroperations

all but write and admin

allows read only access in TrackMe

trackme_power

trackmepoweroperations

*/write

allows management of TrackMe entities but not the creation of new content (such as trackers)

trackme_admin

trackmeadminoperations

*/admin

allows content management such as the creation of tenants and trackers

As a summary:

  • When defining your own roles integration, you can choose to have users being a member of TrackMe builtin roles, or you can choose to inherit these roles into your own roles to grant TrackMe capabilities accordingly.

  • A member of a role providing the trackmeadminoperations capability can create tenants and scheduled logics (trackers) even if the user Splunk permissions do not normally allow the creation of scheduled knowledge objects, this made possible only in TrackMe for TrackMe context via TrackMe’s REST API and through elevation of privleges according to the user’s capabilities.

  • If a user which does not own the trackmepoweroperations capability attempts to perform a write operation through an associated REST endpoint, Splunk will refuse access to this endpoint.

  • Similarly, a user which does not own the trackmeadminoperations attempts to reach any of the admin related REST endpoints, Splunk will refuse access to the requested endpoint.

Definition of RBAC and ownership at the creation phase of the Virtual Tenant

Consider the following example:

  • A Virtual Tenant is created for the purpose of the SIEM quality control operations for our ACME EMEA department

  • The tenant is created with TrackMe indexes dedicated to this department

  • The tenant is created with specific roles allowing its administration, and roles allowing a non privileged access to the tenant

  • Access to the these indexes as well as the administration and user access are provided by two Splunk roles, emea_siem_admin for admin and emea_quality_control for normal user accesses

  • Althrough it is not mandatory, the ownership is set to a service account user srv-trackme to facilitate further control for Splunk administrators

Hint

Preset RBAC for the tenant creation UI

  • Since the version 2.0.52, you can preset values for the owner and roles when creating a new Virtual Tenant from the UI

  • Go in the Configuration then General Configuration

screen1.png

Defining RBAC when creating new Virtual Tenants:

screen1.png screen2.png

Once the tenant has been created, we can observe the permissions and ownership carefully defined by TrackMe:

screen3.png

Althrough we may have several tenants in the environmment, TrackMe will provide access to the tenants according to the RBAC policies, for instance a full admin access shows all existing tenants:

screen4.png

A user member of our emea_quality_control role will only see and be able to access to list of granted Virtual Tenants:

screen5.png

Updating RBAC policies and ownership assignement for an existing Virtual Tenant

TrackMe allows updating the Role Based Access Control policies as well as the ownership of an existing Virtual Tenant.

Updating RBAC through the Virtual Tenant user interface

Access to the Virtual Tenant user interface, double-click on the tenant and access its administration screen:

screen7.png screen8.png screen9.png

Carefully update the ownership and/or RBAC policies, TrackMe will update the Virtual Tenant configuration, all of its knowledge objects will be re-assigned if necessary, and their permissions updated accordingly.

Updating RBAC through the REST API

You can equally update the RBAC policies and ownership through the REST API endpoint:

screen11.png

For instance, say we want to add an additional user role access siem_users to our tenant siem-quality-control, we could run:

| trackme url=/services/trackme/v2/vtenants/admin/update_tenant_rbac mode=post body="{ 'tenant_id': 'siem-quality-control', 'tenant_roles_admin': 'emea_siem_admin', 'tenant_roles_power': 'emea_siem_power', 'tenant_roles_user': 'emea_quality_control,siem_users', 'tenant_owner': 'srv-trackme'}"