What is the best way to deal with lookup and multi tenancy set-ups?

[kozanic_FF]

Hi Gurus,

Hoping someone out there might be able to provide some guidance on how best to deal with the current situation I'm trying to figure out — if it's even possible.

We provide support for a number of different clients, and as part of that, we are building up Splunk to monitor these clients' environments, and building a centralized dashboard.

Per client — we would also like to provide a portal that will allow them to view pre-built dashboards / report etc.

All of this I have under control I think — using permissions limit the data visible, and apps to provide the portal with Dashboards etc.

The bit that has me stuck is lookups. We have a number of lookups that define things like alert thresholds, etc. ATM, these are all set up in a centralized fashion with all clients data in there to power our Alerts and Dashboard.

I do not want to allow one client to see another clients info, and have thought about creating client specific lookups that only contain their data, and storing that in their app.

Many of the lookups are configured as automatic and tied to specific sourcetypes. I'm assuming that I will only be able to configure the automatic lookups once, and which ever has the highest precedence, will be the one that's loaded.

Just wondering if there is a way that I can use automatic lookups to meet my needs (in a way that means I don't have to update my portal dashboards every I create a new one) — or if I have to use manual look ups for the client portal dashboards — referencing their specific lookup data.

[woodcock]

There is also another multi-tenancy/multi-vendor SIEM product coming soon. You can email me about it if you like.

[jkat54]

I create each team their own app and roles that map to their indexes and read/write perms in their app.

This keeps their lookups in their apps. Which then means the lookups are only available to people who have access in that app, and then we log into the UI manually and set their app as their defaul splunk app for their role.

[kozanic_FF]

Thanks jkat,

This is pretty much what I'm already doing - but as mentioned by Woodcock, I don't think Splunk is actually capable of doing what I want yet which is to be able to set-up automatic lookups for 1 sourcetype, but using different files depending on the user.

[jkat54]

yeah, no idea how you could achieve that currently unless you used a macro and many lookup files.

i've done things like this before

| inputlookup [subsearch with if/case condition that returns the lookup name] ...

If you macro'd that and appended it to their search strings it might be a work around.

[jkat54]

See this generic example of how to map out the RBAC model per search app:

[woodcock · Accepted solution]

Generally this is done by having separate Splunk Indexers. At the moment, this is really the only practical way. However, there is a beta from Splunk that is nearing completion called Mothership that is supposed to address the multi-tenancy gap in Splunk. Supposedly there will be some announcements soon. That is all I know about it.

[kozanic_FF]

Thanks Wookcock.

Unfortunately we are not in a position to be able to run separate indexers - currently on Splunk Cloud (5GB Plan).

I'll have a play with creating the lookups in the apps to see if will work as I hope, but suspect that I will have to reference manually rather than having them set to automatic.

Looking forward to hearing more about Mothership!

[Doc_Yes]

Mothership is now available for free https://splunkbase.splunk.com/app/4646/

[woodcock]

You beat me too it. It was just released today.

[jkat54]

There's no need for separate indexers IMHO... as long as you're dealing with a cluster here and not a stand alone instance, it's not trivial but doable:

You can force SplunkD communications to ssl and only to allow certain client certs (as well as setting pass4SymmKey) to effectively stop other rogue search heads from accessing your data. Then so long as you have a rock solid RBAC model on the search heads you're allowing to access your data... you're good to go.

You can use the strategy I explained below with a high degree of certainty.