[FEATURE] Enable/Disable Multi-Tenancy, Private Tenant and set Default Tenant in OS Dashboards.

[abhivka7]

Is your feature request related to a problem?
Dashboards security plugin offers customers the feature to have multiple tenants for each user. This feature is called multi-tenancy. Under this feature, users can have global tenant, private tenant and custom tenants. But having so many tenant options can cause confusion among users if they don't want to use multi-tenancy feature. Therefore there should be an option to enable/disable multi-tenancy and private-tenant to avoid confusion and save space on unwanted indexes.

Right now we have the option to change these options in opensearch_dashboards.yml, but that requires a restart of Dashboards env. We want to make these changes dynamic from Dashboards page.

Also whenever user logs in, dashboard security plugin uses the last used tenant from previous session to login. But there is no way to choose a default tenant whenever a user logins for the first time. There should be an option to set a Default-Tenant out of all available tenants dynamically for better user experience.

What solution would you like?
There should be an option to :

1. Enable/Disable multi-tenancy as and when required by user.
2. Enable/Disable private-tenant.
3. Set a Default Tenant out of all available tenants.

cc: @prabhat-chaturvedi

[RyanL1997]

Hi @abhivka7, thanks for filing this issue. I believe you can change these preference by modifying the opensearch_dashboards.yml with following configurations:

opensearch_security.multitenancy.enabled: true
opensearch_security.multitenancy.tenants.preferred: ["Private", "Global"]
opensearch_security.multitenancy.tenants.enable_global: true
opensearch_security.multitenancy.tenants.enable_private: true

For more informations: https://opensearch.org/docs/latest/security-plugin/multi-tenancy/multi-tenancy-config/

[stephen-crawford]

[Triage] Thank you @RyanL1997 for already following up on the issue. Closing since it appears to be resolved. Thank you!

[abhivka7]

Hi @RyanL1997 . We can modify these changes from opensearch_dashboards.yml but we want to do this dynamically. Sorry I forgot to mention that earlier in description, I have updated the description with that.

[devardee]

@scrawfor99 requesting you to re-open the issue. The settings that @RyanL1997 mentioned are static settings. @abhivka7 is proposing to make them dynamic.

[peternied]

@abhivka7 Could you provide more background on why you'd like these feature to be dynamic?

I am having trouble imagining a scenario where an administrator would enabling multi-tenancy on cluster with active users and then disabling it causing them effectively data loss. Same for the private tenant to be enabled/disabled

Default tenant that makes a lot of sense to me, but it might be worthwhile to tackle that separately from those other two items.

[cwperks]

[Triage] @jimishs @shanilpa There is a request to be able to dynamically enable/disable multi-tenancy in dashboards without an OSD reboot. Is this something that should be supported?

[jimishs]

Thanks @abhivka7 for starting this thread. I would refine the description based on the usecases we have heard from the customers

Recommendations to refine the requirement

1. Request to disable private tenant - 1) customers do not want any of their users to have separate views 2) First time user log in for every user results in a private index created, that skews the shard balancing operations, as there isnt currently a differentiation between data indices and metadata indices
2. Request to disable multi tenancy - 1) customers who are looking to have only one single tenant (essentially no tenant) for their users 2) customers who want to make it easier to shared index patterns and saved objects across all users (tenants dont support this today). Sometimes this decision is made after the cluster is created, hence customers need a way to change this setting.

Regarding data loss - the current thinking is that when customers disable multi tenancy, we make the indices unavailable immediately. We can refine this requirement on when its appropriate to delete the indices (eg: after 7 days or 14 days as an example). This will protect accidental configuration changes.

Thanks @cwperks @peternied for your feedback. Let us know if you have additional questions.

[peternied]

customers need a way to change this setting

There is a way to change this setting, update the configuration file and restart the cluster, is there a reason this mechanism cannot be used?

[abhivka7]

@peternied what you suggests requires a cluster restart. We want to make these changes dynamic.

[peternied]

@abhivka7 @jimishs What is the problem we are trying to solve? Why does this need to be any more dynamic than the other settings in OpenSearch / Dashboards' configuration files.

For your consideration, if OpenSearch and Dashboards had a 'reload the cluster' API that shutdown all nodes, reloaded config from disk, brought the node back online, would that be what you need and support a broader set of setup scenarios?

[stephen-crawford]

[Triage] A new API (heavily guarded & warned) would be a great option for addressing this issue as well as several other issues related to configuration options.

[varun-lodaya]

@peternied not really. Actually, the current mechanism of updating YAML files on nodes to modify tenancy is not really a scalable approach. Imaging large clusters(100+) where there are 100s of nodes. Operators have to either manually update all or build automation to update them, plus, it's destructive. This GH issue is mainly to make this seamless through APIs. We can debate if we want to follow the same model for lot of configuration as well but we have to start somewhere.

[abhivka7]

One more point here is if there are multiple nodes and the user forgets to update the YAML file on some of them, then user experience may vary depending on which node the request hits. This feature fixes this problem.

[stephen-crawford]

Hi @varun-lodaya and @abhivka7. Thank you for your detailed thoughts about the issue. I understand your concern about the scalability of the current YAML-based approach. One concern that was brought up during the triaging meeting was the potential for a dynamic API like you are suggesting to lead to a loss of data. After you have enabled multi-tenancy and operated with it, we don't want users to accidentally lose their data by then disabling it--wiping what they have done. The YAML-based approach is seen as somewhat safe since it requires a great deal of intent to make the change. An API call may be something that is harder to ensure the user has a full understanding of the ramifications. Perhaps a warning about this is enough to cover the concern? I was wondering if you had any thoughts about how you would like to see this handled?

[abhivka7]

Hi @scrawfor99. Disabling multi-tenancy won't lead to any loss of data. Users will only be unable to access tenant index. Data will still be in the respective tenant index that users can access if absolutely needed after discussing with admin. Hope this helps.
Regarding your concern:
The YAML-based approach is seen as somewhat safe since it requires a great deal of intent to make the change.
Only admin will have the permission to change tenancy settings using api or console. As @varun-lodaya mentioned, in case of 100+ nodes, it's nearly impossible to change this setting and missing any one node can cause bad user experience.

[peternied]

I stand corrected, I did some digging, from the documentation [link] Certain settings, however, require opensearch.yml. In general, these settings relate to networking, cluster formation, and the local file system. This is a good basis for the kinds of things that should be dynamic - including tenancy being enabled/disabled.

The backend security configuration can by dynamically updated, which causes the whole plugin to reload so technically this is possible so long as this configuration is enabled. The gap is that the dashboard settings are not following this model. I think it makes sense to open up the dashboard security configuration to be dynamic as well.

In a world where the implementation this is making all settings from the yml file dynamically updatable by cooridnation and update of the BE and FE - I am wholly onboard. If there are some settings that cannot be included I would be curious what is holding them back.

@abhivka7 & @varun-lodaya it sounds like you have been thinking about this for a while, do you have a design to discuss in more detail or a draft PR?

[prabhat-chaturvedi]

@peternied Trying to reduce the scope of this Feature limited to tenancy related configurations only. We are conducting a POC for the initial design will update here the proposal.

[abhivka7]

We are taking the conversation to RFC: opensearch-project/OpenSearch#5853
Everyone please post any follow-up questions there.
Thanks.

[peternied]

@abhivka7 Since the conversation has moved to another repo lets close out this issue if it won't be followed up on.