Overview of teams in ITSI
Teams provide presentation-layer security only and not data-level security. It's still possible for a user with access to the Splunk search bar to look up ITSI summary index data.
Teams in IT Service Intelligence (ITSI) help you restrict service-level information to only the departments or organizations that need access to that information. Teams empower domain experts in different areas within an organization to create and monitor the services that pertain to their department. For information about setting up teams in your environment, see Implement teams in ITSI.
If your organization doesn't need to restrict service visibility to specific areas within your organization, you don't need to implement teams.
To restrict service-level information in ITSI, 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 only belong to only one team. If a user doesn't have read access to a team, they cannot see data from the services within that team in the following object types:
- Glass tables
- Service analyzers
- Deep dives
- Correlation searches
- Multi-KPI alerts
- Episode Review
Note that users with restricted access to service-level information might still be able to edit other information in a glass table, deep dive or other visualization if they have write permissions for that object.
How teams differ from other access controls in ITSI
Teams provide another level of access control on top of those delivered by default with IT Service Intelligence.
ITSI is delivered with ITSI-specific roles. These roles have capabilities that control access to different features in ITSI. You can change the capabilities assigned to roles as needed. For more information, see ITSI capabilities reference.
You can also set read/write permissions for glass tables, deep dives, and other ITSI objects. For more information, see Set permissions to ITSI views for more information.
Teams restrict read/write permissions to the underlying objects within ITSI visualizations, such as KPI base searches.
For example, a user might have permission to view a particular glass table. However, 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 is not displayed. Only the data related to services for which the user has read access appear on the glass table.
What's in the Global team?
By default, all ITSI objects are contained within the default Global team. If you don't need to restrict service visibility to specific teams in your organization, create all services in the Global team. You cannot delete the Global team.
The following objects can only be created in the Global team and cannot belong to a specific team:
- Service templates
- KPI templates (provided by modules)
- KPI base searches
- KPI threshold templates
Global team permissions
The itoa_admin role has write access to the Global team and can change permissions on the Global team. All other roles have read access. Read access ensures that services contained in other teams can still use objects in the Global team.
If you have the itoa_admin or itoa_team_admin role, or the capabilities of these roles, you need write access to the Global team to write and delete global objects such as service templates, entities, KPI templates, base searches, and threshold templates.
Team admin role
itoa_team_admin role is delivered with ITSI to help departmental or area admins manage services for a team. This role has all of the capabilities of the
itoa_admin role with the exception that it cannot perform backups and restores, perform bulk imports of entities and services, or create service templates.
itoa_team_admin role cannot create new teams. The
itoa_admin role creates teams and has read/write access to all private teams that are created, as well as to the Global team.
Create custom roles 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 users and roles in ITSI.
For example, the Splunk administrator performs the following steps:
- Creates an
itoa_finance_adminrole for the admin of the Financial department.
- Creates an
itoa_sales_adminrole for the admin of the Sales department.
- Assigns read/write permissions to the
itoa_finance_adminrole for the Finance team.
- Assigns read/write permissions to the
itoa_sales_adminrole for the Sales team.
As a result, the
itoa_finance_admin role can create services in the Finance team and the
itoa_sales_admin role can create services in the Sales team.
Leverage 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 services for their department with a dependency on the basic services as necessary.
The administrator 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 team-specific services as needed.
Restrict access to objects in ITSI
Implement teams in ITSI
This documentation applies to the following versions of Splunk® IT Service Intelligence: 4.2.0, 4.2.1, 4.2.2, 4.2.3, 4.3.0, 4.3.1, 4.4.0, 4.4.1, 4.4.2, 4.4.3, 4.4.4, 4.4.5