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 let you restrict service-level information in IT Service Intelligence (ITSI) 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. If your organization doesn't need to restrict service visibility to specific areas within your organization, you don't need to implement teams. For information about setting up or viewing the teams in your environment, see Create teams in ITSI.

An ITSI administrator creates teams and assigns write permissions to them by role. When you create a service, you specify the team it belongs to. A service can only belong to one team.

If a user doesn't have read access to a team, they can't 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

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 ITSI.

Without teams

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 and write permissions for glass tables, deep dives, and other ITSI objects. For more information, see Configure users and roles in ITSI.

With teams

Teams restrict read and 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 doesn't have read permission, the KPI value isn't 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 can't delete the Global team.

The following objects can only be created in the Global team and can't belong to a specific team:

• Service templates
• Entities
• KPI templates (provided by modules)
• KPI base searches
• KPI threshold templates

The Global team contains common services shared across all departments. The ITSI administrator, using the itoa_admin role, configures the deployment and creates services in the Global team that are common and used across departments.

Each team admin, with roles inherited from the itoa_team_admin role, creates services for their department with dependencies on Global services, if needed. Members of a specific team can't view services in another team.

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.

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 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

The itoa_team_admin role is delivered with ITSI to help departmental admins manage services for their team. This role has all the capabilities of the itoa_admin role, except it can't perform backups and restores, perform bulk imports of entities and services, or create service templates.

The itoa_team_admin role can't create new teams. The itoa_admin role creates teams and has read and write access to all teams that are created, as well as to the Global team.

The administrator creates custom roles for each departmental admin that will manage a team in ITSI. These team admin roles must inherit from the itoa_team_admin role to obtain the appropriate capabilities. For more information about this role's capabilities, see Configure users and roles in ITSI.

Example

In the following example, an ITSI administrator wants to create three teams within ITSI: a finance team, a sales team, and an engineering team.

The administrator performs the following steps:

1. Creates an itoa_finance_admin role for the admin of the Financial department.
2. Creates an itoa_sales_admin role for the admin of the Sales department.
3. Creates an itoa_eng_admin role for the admin of the Engineering team.
4. Assigns read/write permissions to the itoa_finance_admin role for the Finance team.
5. Assigns read/write permissions to the itoa_sales_admin role for the Sales team.
6. Assigns read/write permissions to the itoa_eng_admin role for the Engineering team.

As a result, the itoa_finance_admin role can create services in the Finance team, the itoa_sales_admin role can create services in the Sales team, and the itoa_eng_admin can create services in the Engineering team.

The following diagram shows how read and write permissions are assigned within the three teams: