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 tenant 2 and 3 are not available to employees of tenants 2 and 3.
  • Alerts and their linked events can be accessed by employees of the main tenant.

Page top