Is your feature request related to a problem?
In our current enterprise environment, we utilize Multi-Tenancy to provide organized spaces for various application teams. However, we have observed that monitors and alerts do not seem to stay strictly within the boundaries of a specific tenant.
Because many of our users share common Active Directory (ADOM) groups for broad system access, they often share the same backend roles. Even with plugins.alerting.filter_by_backend_roles: true enabled, a user logged into "Tenant A" can still see and interact with monitors created in "Tenant B" if their shared backend roles overlap. This creates an overlapping view that can make it difficult for teams to manage their own specific alerts without seeing the configurations of other departments, which we would like to help them avoid.
What solution would you like?
We would appreciate a feature that allows monitors to be strictly associated with the Tenant ID in addition to the user's backend roles. Ideally, the Alerting plugin would treat the tenant as a primary isolation layer.
The desired behavior would involve:
- Tenant-Aware Storage: When a monitor is created, the system would automatically tag it with the specific Tenant metadata.
- Contextual Filtering: The API and UI would filter results based on the securitytenant header of the current session. This ensures that a user only sees monitors belonging to the tenant they are currently working in, providing a much cleaner and more focused experience for each application team.
- Enhanced Isolation: An optional configuration setting that enforces this tenant-level check before returning any alerting metadata to the requester.
What alternatives have you considered?
We have carefully evaluated a few other paths, but they present some operational challenges:
- Granular Role Mapping: We considered creating unique backend roles for every individual application. However, in a large organization, this would lead to an extremely high number of roles, which becomes difficult to maintain and audit over time.
- Workspaces: We looked into the Workspaces feature, but since our current security requirements rely on the hard isolation provided by Multi-Tenancy, we are unable to utilize Workspaces as a primary solution.
- Separate Clusters: While separate clusters would solve the isolation, it would significantly increase our infrastructure costs and reduce the benefits of having a centralized observability platform.
Do you have any additional context?
Our goal is to ensure that OpenSearch can scale gracefully within a large enterprise where user groups are often broad. By aligning the Alerting plugin more closely with the Multi-Tenancy model, OpenSearch would provide a more intuitive experience where a "Tenant" truly acts as a self-contained environment for all resources, including monitors and alerts. This would greatly assist our teams in maintaining their own configurations without the risk of cross-tenant visibility.
Current Behavior: Identity (Roles) -> Access to all monitors matching those Roles (Global across Tenants)
Desired Behavior: Identity (Roles) + Active Tenant Context -> Access only to monitors within that Tenant
Is your feature request related to a problem?
In our current enterprise environment, we utilize Multi-Tenancy to provide organized spaces for various application teams. However, we have observed that monitors and alerts do not seem to stay strictly within the boundaries of a specific tenant.
Because many of our users share common Active Directory (ADOM) groups for broad system access, they often share the same backend roles. Even with plugins.alerting.filter_by_backend_roles: true enabled, a user logged into "Tenant A" can still see and interact with monitors created in "Tenant B" if their shared backend roles overlap. This creates an overlapping view that can make it difficult for teams to manage their own specific alerts without seeing the configurations of other departments, which we would like to help them avoid.
What solution would you like?
We would appreciate a feature that allows monitors to be strictly associated with the Tenant ID in addition to the user's backend roles. Ideally, the Alerting plugin would treat the tenant as a primary isolation layer.
The desired behavior would involve:
What alternatives have you considered?
We have carefully evaluated a few other paths, but they present some operational challenges:
Do you have any additional context?
Our goal is to ensure that OpenSearch can scale gracefully within a large enterprise where user groups are often broad. By aligning the Alerting plugin more closely with the Multi-Tenancy model, OpenSearch would provide a more intuitive experience where a "Tenant" truly acts as a self-contained environment for all resources, including monitors and alerts. This would greatly assist our teams in maintaining their own configurations without the risk of cross-tenant visibility.
Current Behavior: Identity (Roles) -> Access to all monitors matching those Roles (Global across Tenants)
Desired Behavior: Identity (Roles) + Active Tenant Context -> Access only to monitors within that Tenant