Possibility of Multitenancy with ES

[PickleRick]

I'm wondering about possibilities to set up a separate ES's for different teams.

Due to some mergers and acquisitions one of our customers is beginning to be in a positions where single ES covering whole enterprise is not a good model.

I already found that ES on its own does not support multitenancy and I would need a separate instance for each team/suborganization/whatever. But I don't think it's that easy.

Of course we can set up a separate SH cluster for separate teams and install separate ES instances but if they operated on the same indexer cluster they would share notable index and all datamodels. If we wanted, we could define separate datamodels for them to use but then we would have to edit all the security content that by default uses CIM, right?

Any other possibilities?

Split notable index? (Multiple indexers holding "own" version of this index) Seems possible but very very ugly and hard to maintain.

[gcusello · Accepted solution]

Hi @PickleRick,

I already implemented a multitenency ES installation but it was a very hard work and required the support of Splunk Professional Services.

You could segregate data using different indexes for each tenant, the problem is that you have also to manually modify all Correlations Searches, all DataModels and all Threat Intelligence components to manage multitenancy, and it isn't a very easy work, especially Threat Intelligence.

In conclusion: it's possible but you need an help of an ES expert Splunk Architect and maybe also of Splunk PS, and anyway consider many days to make this job (we worked for around 90 days without take in consideration the time of the customer paople).

Make your considerations if it's less expensive ho manage two ES infrastructures or one multitenancy.

Ciao.

Giuseppe

[PickleRick]

That's exactly what I thought - considering all the TI and security content which is standardized to the CIM datamodels it would be a huge PITA.

Setting up two separate infrastructures does seem tempting but we still have some need of "oversight" which means that we probably effectively end up with two separate indexer clusters, two searchhead clusters (each with own instance of ES)... and one searchhead cluster searching from both indexer cluster. Seems... a bit overcomplicated.

And I didn't even mention UBA yet... *facepalm*.

Anyway, thanks for confirmation of my suspicions.