I was wondering on if there was any roadmap info on how Spaces/SG Tenant features would be integrated in the future? Looking to start using SG Tenants soon but don’t want to implement in the wrong way.
SG Tenants implemented under Spaces. Each Space can have many SG Tenants.
SG Tenants implemented above Spaces. Each SG Tenant has their own Spaces
SG Tenants map directly to Spaces. SG Tenant = Space.
2) is the way to go but i'am wondering why do you want use Spaces AND multitenancy. Can you elaborate your use case a bit?
Am 27.01.2019 um 19:53 schrieb Brian <briansrch@gmail.com>:
I was wondering on if there was any roadmap info on how Spaces/SG Tenant features would be integrated in the future? Looking to start using SG Tenants soon but don't want to implement in the wrong way.
1) SG Tenants implemented under Spaces. Each Space can have many SG Tenants.
2) SG Tenants implemented above Spaces. Each SG Tenant has their own Spaces
3) SG Tenants map directly to Spaces. SG Tenant = Space.--
You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/50dca6e0-bb25-4734-987d-5a18c12eda68%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.
Of the three options, #2 or #3 would be preferable. #2 definitely works.
Spaces plus tenants? Multi-tenancy where tenants want control of their own spaces. Allows more flexibility, distributed administration, sandbox Kibana environments, etc.
Thanks. Maybe we something in SG7 but the main problem is that Spaces are not OSS (but part of the ES basic license which is free but not OSS)
and we can not rely on Spaces for our own MT implementation because of that.
Am 06.02.2019 um 00:02 schrieb Brian <briansrch@gmail.com>:
Of the three options, #2 or #3 would be preferable. #2 definitely works.
Spaces plus tenants? Multi-tenancy where tenants want control of their own spaces. Allows more flexibility, distributed administration, sandbox Kibana environments, etc.
--
You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/a08a2bc2-d8bd-41ce-92d7-40c44bceaf4c%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.
That makes sense. Thank you for the explanation and responses. This was mostly just understanding the future roadmap so that I don’t introduce a feature to users but then have to remove it or change it significantly later.
Think of a large organization where there are many different business segments and different use cases. Different segments in the same business may not even talk to each other but have a desire to use the same centralized system, ‘privately’, from each other. Or alternatively they may all need access to the same data, but they wish to have their own private workspace in which to work with that data. SG Tenants feature is a true form of ‘private’ in the sense that each tenant from the perspective of Kibana is isolated from each other.
With the non-OSS limitations of the Spaces licensing, #2 would definitely work for any use case I could imagine. It also allows for an easy transition from SG Tenants without Spaces, to SG Tenants with their own Spaces (if/when you decide it is worth implementing). SG Tenants are the mechanism for tenancy and Spaces are used more as a folder structure to organize visualizations and dashboards.