Version: 7.x-36.0.0

This is a technical preview. Technical preview features are not fully supported, may not be functionally complete, and are not suitable for deployment in production. We encourage you to try them out and provide your feedback, good and bad, on the Search Guard forum. This will help us improve and add any features you might be missing.

Multi tenancy

Signals is fully compatible with Search Guard multi tenancy. To use multi tenancy with Signals, make sure it is enabled in sg_config.yml first:

sg_config:
  dynamic:
    do_not_fail_on_forbidden: true 
    kibana:
      multitenancy_enabled: true

How it works

Signals multi tenancy works very similar to Kibana multi tenancy.

By using multi tenancy, you can separate the management and execution of watches by tenant:

  1. Watches in one tenant will not be accessible for users in another tenant.
  2. Execution of watches in one tenant will not interfere with execution of watches in another tenant.

API permissions

Access to the Watch REST API can be granted per tenant as well.

sg_signals_multitenancy:
  cluster_permissions:
    ...
  index_permissions:
    ...
  tenant_permissions:
    - tenant_patterns:
        - 'tenant_1'
      allowed_actions:
        - 'SGS_SIGNALS_WATCH_MANAGE'
    - tenant_patterns:
        - 'tenant_2'
      allowed_actions:
        - 'SGS_SIGNALS_READ'

In the example above, a user with the sg_signals_multitenancy role has manage permissions for watches in tenant_1, and read only permissions for watches in tenant_2.

Watch execution in multi tenancy mode

When watches are executed in multi tenancy mode, a thread pool is created for each tenant. This means that execution of watches in one tenant will not interfere with execution of watches in other tenants.


Not what you were looking for? Try the search.