Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
Describe the issue: OpenSearch - Tenants vs Workspaces - Which one is better ?
Configuration: Is OpenSearch Tenants model will be deprecated ? We have the OpenSearch cluster setup for our business unit with 190+ applications. Which is best option if we need to onboard these applications into OpenSearch primarily for log monitoring ? These applications are managed by different teams or some teams are common for a few apps. We wanted to keep them isolated so these will be managed individually and App 1 cannot see or access App 2 logs or dashboards or alert rules etc.
Relevant Logs or Screenshots:
@Santhosh.Gollapudi based on your use case, tenant and tenant permissions would be a good option. You can assign multiple roles to the same team, which will provide added to the relevant tenant. The users would need to change between tenants to see dashboard object (visualisations etc ) specific to that particular tenant.
Hope this helps
Hi @Anthony - Looking at this closed github issue.
http://github.com/opensearch-project/security/issues/1869
Does it make more sense to implement workspaces instead of multi tenancy ?
Hi @Anthony
What is the main reason for your recommendation to go with Tenants instead of workspaces? Is the isolation of saved objects like dashboards, visualizations, alerts, monitors, etc ? the ability for a user, belonging to workspace 1, to manage an alert or monitor that belongs to Workspace 2 ?
@muraliv The main reason would be the maturity of the tenants vs workspaces. And the documentation available. Tenants are fully shipped and battle-tested. Workspaces were still being RFC’d and it seems the requirements are still being defined.
For the use case outlined above it would seem to me that the tenants would be the simplest option forward.
It’s also worth mentioning that both solutions are really about dashboard object isolation and not data isolation, which is achieved via roles and permissions.
What is the future roadmap ? Workspaces will be directional or both tenants and workspaces will continue ?
To add to what @Anthony mentioned — for your specific use case of 190+ applications needing strict isolation for logs, dashboards, and alert rules, the Tenants model is the right choice right now for a few practical reasons:
The Tenants model already has a solid permission system where you can scope index patterns and dashboards per tenant. With multi-tenant setups at this scale, you’ll want to map team roles to tenant access so teams can switch context via the tenant selector rather than needing separate clusters.
As for the roadmap question, Workspaces are still being actively designed and the feature requirements are evolving. Given that your use case is well-served by Tenants today, I’d recommend building on that and watching the Workspaces RFC thread for when it stabilizes. The OpenSearch GitHub project has the Workspaces discussion if you want to track its progress or provide input.
Are there some objects like alerts or monitors global ? Can a user from one tenant able to make changes to or delete an alert created by another user from another tenant?
My teammate found this in the documentation that should have helped restricting a user to see or modify alerts from another tenant space.
PUT _cluster/settings
{
"persistent": {
"plugins.alerting.filter_by_backend_roles": "true"
}
}
I re-read the documentation and it says if a user has at least one common backend role, he/she should be able to see the alerts. With all of us being part of a domain, there is 100% chance of a ADOM group overlap.
Is there an option to retrieve only the roles that are configured instead of getting all the ADOM groups ?
Thanks
Can you please give us a link to this thread ?
I’ve tested this locally with 3.6, including "plugins.alerting.filter_by_backend_roles": "true"
and was not able to get monitor isolation working using either tenants or workspaces.
Regarding the filter_by_backend_roles, it seems the user block stopped being written in some earlier version and even when it is written (via direct REST API), the filter doesn’t exclude results as it should.
Monitors are saved in .opendistro-alerting-config which is not managed by tenants or workspaces, therefore the use has access to all of monitors (assuming they have access to the index)
It seems at this moment, you can either limit the user from seeing any monitors, or seeing them all.
I would recommend to raise a feature request for this here
In our case we are actually moving from tenants to workspaces, as the latter seems like the way forward. I had raised a relevant thread on slack:
It’s true that now security roles no longer have “Tenant permissions”, as Workspaces have their own ACL, so we need to define the relevant permissions for the relevant people both on security plugin level and on dashboards separately. Since we’ve automated that it is not a big problem but indeed it’s a compromise to get into the future view already. At the same time, as Dashboards is moving towards a Grafana-like product with multiple data sources (not just OpenSearch), it makes sense that ACLs for Dashboards objects are kept on Dashboards-side.
Also, workspaces have the concept of “use-case” so that each team can have a more focused environment, i.e, if a team only cares about simple Discover, Vizualisations and Dashboards, the “Essentials” use-case only show them those menu items, hiding the plethora of irrelevant features.
We have a workaround to make sure that a user from tenant1 is not able to see a monitor created by a user from tenant2. This is by adding this to the rolesearch in the authz section of ldap configuration.
rolesearch: "(&(|(cn=CSG_OPENSEARCH*)(cn=elm_*))(member={0}))"
userroleattribute: null
userrolename: "disabled" <changed from null to disabled>
Thanks
Murali