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:
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 andemea_quality_control
for normal user accessesAlthrough 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
Defining RBAC when creating new Virtual Tenants:
Once the tenant has been created, we can observe the permissions and ownership carefully defined by TrackMe:
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:
A user member of our emea_quality_control
role will only see and be able to access to list of granted Virtual Tenants:
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:
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:
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'}"