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 TenantIdevent 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.
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):
The collector of tenant 2 receives and forwards events to the correlator.
When correlation rules are triggered, the correlator creates correlation events with tenantID=2.
The correlator forwards the correlation events to the storage partition of tenant 2.
An alert is created and linked to the tenant with tenantID=2.
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):
The collector of tenant 2 receives and forwards events to the correlator.
When correlation rules are 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 tenant with tenantID=1.
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.
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:
The collector of tenant 2 receives and forwards events to the correlator.
The collector of tenant 3 receives and forwards events to the correlator.
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.