Overview of service-level permissions in ITSI
As an ITSI administrator, you can set read/write permissions on services so that certain user roles cannot see or modify certain services. This enables you to restrict service-level information in ITSI to only the departments or organizations that need access to the information. The use of service-level permissions also enables an ITSI administrator to empower domain experts in different areas within the organization to create and monitor the services in ITSI that pertain to their department or area.
If your organization does not need to restrict service visibility to specific areas within your organization, you do not need to use service-level permissions.
To restrict service-level information in ITSI, you create teams and assign permissions to the teams by role. When you create a service, you specify the team it belongs to. A service can belong to only one team. Users without read access to a team cannot see data from the services within that team in:
- Glass tables
- Service analyzers
- Deep dives
- Correlation searches
- Multi-KPI alerts
- Episode Review
Users with read-only access to a team can see data from services within that team in glass tables, service analyzers, deep dives, correlation searches, multi-KPI alerts, and Episode Review, but cannot edit or delete any of the service-level data. Note that users with restricted access to service-level information may still have the ability to edit other information in a glass table, deep dive or other visualization if they have write permissions for that glass table, deep dive, or other object.
Service-level permissions provide presentation layer security only and not data level security. It is still possible for a user with access to the Splunk search bar to look up ITSI summary index data.
How service-level permissions differ from other access controls in ITSI
ITSI is delivered with ITSI-specific roles that are assigned capabilities that control access to different features in ITSI. You can change the capabilities assigned to roles as needed. See List of capabilities for more information.
ITSI also enables you to set read/write permissions for the following ITSI objects:
- Service analyzers
- Glass tables
- Deep dives
- Correlation searches
- Multi-KPI alerts
- Notable event aggregation policies
These permissions determine which user roles have read or write access to specific objects that have been created, such as a shared service analyzer view, a shared glass table, or a correlation search. See Set permissions to ITSI objects for more information.
Teams provide another more granular level of access controls. Teams allow you to restrict read/write access to the underlying objects, such as KPI searches, within these ITSI visualizations. If teams have been created in your organization, a user may have permission to view a particular glass table, but if a KPI in that glass table belongs to a service in a team for which the user does not have read permission, the KPI will not be displayed. Only the data related to services for which the user has read access are displayed on the glass table.
The following objects are contained within the default Global team:
- Service templates
- KPI templates (provided by modules)
- KPI base searches
- KPI threshold templates
These objects can only be created in the Global team. The Global team can also contain services. The Global team cannot be deleted.
The itoa_admin role has read/write permissions to the Global team. All other roles have read permissions. The read permissions allow the objects in the Global team, such as entities, to be used by services in other teams. Only the itoa_admin role can change the permissions on the Global team.
If you do not have a need to restrict service visibility to specific teams in your organization, create all services in the Global team.
If you want to segregate your ITSI data into separate teams for data privacy or administration purposes, create a private team for each department or area in your organization that requires a separate view of service data. All private teams can view and use the objects in the Global team. This enables the team administrator to create services in the private team that use service templates, entities, KPI base searches, KPI templates, and KPI threshold templates in the Global team. Team admins can also create services in a private team that have a dependency on a service in the Global team. A private team can contain services with a dependency on other services within the same team but a service in a private team cannot depend on a service in another private team.
Example of using private teams to segregate data in ITSI
As an example, to keep financial data private, you can create a team for the Finance department and assign the services that pertain to the Finance department to this team. Likewise, you can create a team for the Sales department and assign services pertaining to the Sales department to this team.
A Finance admin role can be created to administer the services for the Finance department and a Sales admin role can be created to administer the services for the Sales department. The Finance admin does not have access to the services in the Sales team and the Sales admin does not have access to the services in the Finance team. Both the Finance admin and the Sales admin can read entities, KPI templates, KPI base searches, KPI threshold templates, and service templates in the Global team and use them for the services in their respective teams, but they cannot modify or delete these objects. The department admins can also create services within their respective teams that are dependent on services in the Global team.
Watch the following video for an example of how you can use private teams to restrict service visibility in ITSI.
ITSI role for team admins
The role itoa_team_admin is delivered with ITSI and provides the ability for departmental or area admins to manage services for a team. This role has all of the capabilities of the itoa_admin role with the exception that the itoa_team_admin cannot perform backup/restores, perform bulk imports of entities and services, or create service templates.
The itoa_team_admin role cannot create new teams. Only the itoa_admin role can create teams. The itoa_admin role has read/write access to all private teams that are created as well as to the Global team.
Create custom roles in the Splunk platform for each ITSI departmental or area admin that will manage a team in ITSI. These roles must inherit from the itoa_team_admin role in order to obtain the appropriate capabilities. For more information about this role's capabilities, see Configure ITSI access controls.
For example, the Splunk administrator (using the admin role) can create an itoa_finance_admin role for the admin of the Financial department and an itoa_sales_admin role for the admin of the Sales department. Then the ITSI admin (using the itoa_admin role) can assign read/write permissions to the itoa_finance_admin for the Finance team and read/write permissions to the itoa_sales_admin role for the Sales team. As a result, the itoa_finance_admin has the ability to create services in the Finance team and the itoa_sales_admin has the ability to create services in the Sales team.
Example of leveraging common services in the Global team
The Global team can contain common services shared across all departments. In this scenario, the ITSI administrator (using the itoa_admin role) configures the ITSI deployment and creates services in the Global team that are common and used across departments. Each department in turn gets a view of ITSI services targeted at the specific department.
The users in a department cannot view the services in another department. Each department leverages common dependencies from the basic services. Each department admin (with roles inherited from the itoa_team_admin role) creates ITSI services for their department with a dependency on the basic services as necessary. The itoa_admin provides support to the admins of the dependent services. The itoa_admin role has full access to view and change the basic services in the Global team as well as Financial, Sales, and Engineering services as needed.
Upgrading from a previous release of ITSI
A default Global team is delivered with ITSI version 3.x. All services, entities, KPI base searches, KPI templates, and KPI threshold templates created prior to version 3.0 belong to the Global team by default. Users possessing the itoa_admin role have full read/write access to the Global team. All other user roles have read only access to the Global team. A user with the itoa_admin role can create private teams and move services from the Global team to the private teams as desired.
Restrict access to objects in ITSI
Implement service-level permissions in ITSI
This documentation applies to the following versions of Splunk® IT Service Intelligence: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.1.0, 4.1.1, 4.1.2, 4.1.5