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.
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:
- Watches in one tenant will not be accessible for users in another tenant.
- Execution of watches in one tenant will not interfere with execution of watches in another tenant.
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
read only permissions for watches in
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.