Working with tenants

Access to tenants is regulated in the settings of users. The general administrator has access to the data of all tenants. Only a user with this role can create and delete tenants.

Tenants are displayed in the table under Settings → Tenants in the KUMA web interface. You can sort the table by clicking on columns.

Available columns:

• Name—tenant name. The table can be filtered by this column.
• EPS limit—quota size for EPS (events processed per second) allocated to the tenant out of the overall EPS quota determined by the license.
• Description—description of the tenant.
• Disabled—indicates that the tenant is inactive.

  By default, inactive tenants are not displayed in the table. You can view them by selecting the Show disabled check box.

• Created—tenant creation date.

To create a tenant:

1. In the KUMA web interface under Settings → Tenants, click Add.

   The Add tenant window opens.

2. Specify the tenant name in the Name field. The name must contain 1 to 128 Unicode characters.
3. In the EPS limit field, specify the EPS quota for the tenant. The cumulative EPS of all tenants cannot exceed the EPS of the license.
4. If necessary, add a Description of the tenant. The description can contain no more than 256 Unicode characters.
5. Click Save.

The tenant is added. Press F5 to refresh the page. After refreshing the page, the created tenant is displayed in the web interface.

To delete a tenant:

1. In the Settings → Tenants section of the KUMA web interface, select the relevant tenant by selecting the check box next to it, then select Delete in the toolbar.
2. This opens the Delete tenant window, which displays information about the tenant and prompts you to enter a code and confirm the deletion of the tenant. If you want to proceed with deleting the tenant, enter the code.
3. Click OK.

The tenant is deleted.

When a tenant is deleted, its services are automatically stopped, except the agents; events are no longer received or processed for the tenant; and the EPS of the tenant is no longer counted towards the cumulative EPS of the license. You can stop the Windows agent services manually in the Start → Services section, and to stop the Linux agent services, you can press Ctrl+C in the terminal in which the agent was started.

Selecting a tenant

If you have access to multiple tenants, KUMA lets you select which tenants' data will be displayed in the KUMA web interface.

To select a tenant for displaying data:

1. In the KUMA web interface, click Selected tenants.

   The tenant selection area opens.

2. Select the check boxes next to the tenants whose data you want to see in sections of the KUMA web interface.
3. You must select at least one tenant. You can use the Search field to search for tenants.
4. Click the tenant selection area by clicking Selected tenants.

Sections of the KUMA web interface will display only the data and analytics related to the selected tenants.

Your selection of tenants for data display will determine which tenants can be specified when creating resources, services, layouts, report templates, widgets, incidents, assets, and other KUMA settings that let you select a tenant.

Tenant affiliation rules

Tenant inheritance rules

It is important to track which tenant owns specific objects created in KUMA because this determines who will have access to the objects and whether or not interaction with specific objects can be configured. Tenant identification rules:

• The tenant of an object (such as a service or resource) is determined by the user when the object is created.

  After the object is created, the tenant selected for that object cannot be changed. However, resources can be exported then imported into another tenant.

• The tenant of an alert and correlation event is inherited from the correlator that created them.

  The tenant name is indicated in the TenantId event field.

• If events of different tenants that are processed by the same correlator are not merged, the correlation events created by the correlator inherit the tenant of the event.
• The incident tenant is inherited from the alert.

Examples of multitenant interactions

Multitenancy in KUMA provides the capability to centrally investigate alerts and incidents that occur in different tenants. Below are some examples that illustrate which tenants own certain objects that are created.

When correlating events from different tenants in a common stream, you should not group events by tenant. In other words, the TenantId event field should not be specified in the Identical fields field in correlation rules. Events must be grouped by tenant only if you must not merge events from different tenants.

Services that must be accommodated by the capacities of the main tenant can be deployed only by a user with the general administrator role.

• Correlation of events for one tenant, correlator is allocated for this tenant and deployed at the tenant

  Condition:

  The collector and correlator are owned by tenant 2 (tenantID=2)

  Scenario:

  1. The collector of tenant 2 receives and forwards events to the correlator of tenant 2.
  2. When correlation rules are triggered, the correlator creates correlation events with tenantID=2.
  3. The correlator forwards the correlation events to the storage partition for tenant 2.
  4. An alert is created and linked to the tenant with tenantID=2.
  5. The events that triggered the alert are appended to the alert.

  An incident is created manually by the user. The incident tenant is determined by the tenant of the user. An alert is linked to an incident either manually or automatically.

• Correlation of events for one tenant, correlator is allocated for this tenant and deployed at the main tenant

  Condition:

  • The collector is deployed at tenant 2 and is owned by this tenant (tenantID=2).
  • The correlator is deployed at the main tenant.

    The owner of the correlator is determined by the general administrator depending on who will investigate incidents of tenant 2: employees of the main tenant or employees of tenant 2. The owner of the alert and incident depends on the owner of the correlator.

  Scenario 1. The correlator belongs to tenant 2 (tenantID=2):

  1. The collector of tenant 2 receives and forwards events to the correlator.
  2. When correlation rules are triggered, the correlator creates correlation events with tenantID=2.
  3. The correlator forwards the correlation events to the storage partition of tenant 2.
  4. An alert is created and linked to the tenant with tenantID=2.
  5. The events that triggered the alert are appended to the alert.

  Result 1:

  • The created alert and its linked events can be accessed by employees of tenant 2.

  Scenario 2. The correlator belongs to the main tenant (tenantID=1):

  1. The collector of tenant 2 receives and forwards events to the correlator.
  2. When correlation rules are triggered, the correlator creates correlation events with tenantID=1.
  3. The correlator forwards the correlation events to the storage partition of the main tenant.
  4. An alert is created and linked to the tenant with tenantID=1.
  5. The events that triggered the alert are appended to the alert.

  Result 2:

  • The alert and its linked events cannot be accessed by employees of tenant 2.
  • The alert and its linked events can be accessed by employees of the main tenant.
• Centralized correlation of events received from different tenants

  Condition:

  • Two collectors are deployed: one at tenant 2 and one at tenant 3. Both collectors forward events to the same correlator.
  • The correlator is owned by the main tenant. A correlation rule waits for events from both tenants.

  Scenario:

  1. The collector of tenant 2 receives and forwards events to the correlator of the main tenant.
  2. The collector of tenant 3 receives and forwards events to the correlator of the main tenant.
  3. When a correlation rule is triggered, the correlator creates correlation events with tenantID=1.
  4. The correlator forwards the correlation events to the storage partition of the main tenant.
  5. An alert is created and linked to the main tenant with tenantID=1.
  6. The events that triggered the alert are appended to the alert.

  Result:

  • The alert and its linked events cannot be accessed by employees of tenant 2.
  • The alert and its linked events cannot be accessed by employees of tenant 3.
  • The alert and its linked events can be accessed by employees of the main tenant.
• The tenant correlates its own events, but the main tenant additionally provides centralized correlation of events.

  Condition:

  • Two collectors are deployed: one on the main tenant and one on tenant 2.
  • Two correlators are deployed:
    • Correlator 1 is owned by the main tenant and receives events from the collector of the main tenant and correlator 2.
    • Correlator 2 is owned by tenant 2 and receives events from the collector of tenant 2.

  Scenario:

  1. The collector of tenant 2 receives and forwards events to correlator 2.
  2. When a correlation rule is triggered, the correlator of tenant 2 creates correlation events with tenantID=2.
     • Correlator 2 forwards the correlation events to the storage partition of tenant 2.
     • Alert 1 is created and linked to the tenant with tenantID=2.
     • The events that triggered the alert are appended to the alert.
     • Correlation events from the correlator of tenant 2 are forwarded to correlator 1.
  3. The collector of the main tenant receives and forwards events to correlator 1.
  4. Correlator 1 processes events of both tenants. When a correlation rule is triggered, correlation events with tenantID=1 are created.
     • Correlator 1 forwards the correlation events to the storage partition of the main tenant.
     • Alert 2 is created and linked to the tenant with tenantID=1.
     • The events that triggered the alert are appended to the alert.

  Result:

  • Alert 2 and its linked events cannot be accessed by employees of tenant 2.
  • Alert 2 and its linked events can be accessed by employees of the main tenant.
• One correlator for two tenants

  If you do not want events from different tenants to be merged during correlation, you should specify the TenantId event field in the Identical fields field in correlation rules. In this case, the alert inherits the tenant from the correlator.

  Condition:

  • Two collectors are deployed: one at tenant 2 and one at tenant 3.
  • One correlator owned by the main tenant (tenantID=1) is deployed. It receives events from both tenants but processes them irrespective of each other.

  Scenario:

  1. The collector of tenant 2 receives and forwards events to the correlator.
  2. The collector of tenant 3 receives and forwards events to the correlator.
  3. When a correlation rule is triggered, the correlator creates correlation events with tenantID=1.
     • The correlator forwards the correlation events to the storage partition of the main tenant.
     • An alert is created and linked to the main tenant with tenantID=1.
     • The events that triggered the alert are appended to the alert.

  Result:

  • Alerts that were created based on events from tenants 2 and 3 are not available to employees of these tenants.
  • Alerts and their linked events can be accessed by employees of the main tenant.