Splunk Enterprise

How do I limit an app to only search one cluster if the SH is connected to several clusters

janlar
Explorer

Currently on 7.1.0 and I have two separate index clusters with different data and purpose, lets name them A and B. I have several search heads cross connected and able to do searches in both clusters (A & B).

Since every search in a SearchHead will search both indexclusters they will generate load on both even if data only exists in one of them. Many apps from different vendors do not specify an exact index resulting in this.

I would like to limit or prevent per app basis that App_1 only can search cluster A, and App_2 only can search cluster B and App_3 can search both cluster A & B.

I can't figure it out how I could do this, please help out here with suggestions.

I guess I had this problem since Before upgrading to 7.1.0 but now it really became a prolbem with datamodels and acceleration backfill as I see remote searches on cluster A for data that doesnt exist there. This is a reported issue SPL-155560, SPL-155219 and I have set the 'acceleration.backfill_time' to limit the index load, but still I have this problem with searches hit both my clusters.

Tags (1)
0 Karma
1 Solution

janlar
Explorer

Update and correction of my post:
The remote searches I see are correct, the data is present at that cluster. The remote search is acceleration backfill and following the guidelines for the bug do resolve them.

About the part how to limit an app I guess I knew the answer already before I wrote the question, but due to stress from my malfunctioning cluster I thought I had remote searches from apps on both cluster even there was no data there. That was partially wrong as an app only searches for data on both clusters if the same index names exits. That also answers the question how to limit an ap, always keep unique names on indexes.

Thank you for your inputs as your comments confirmed my concerns.

View solution in original post

0 Karma

janlar
Explorer

Update and correction of my post:
The remote searches I see are correct, the data is present at that cluster. The remote search is acceleration backfill and following the guidelines for the bug do resolve them.

About the part how to limit an app I guess I knew the answer already before I wrote the question, but due to stress from my malfunctioning cluster I thought I had remote searches from apps on both cluster even there was no data there. That was partially wrong as an app only searches for data on both clusters if the same index names exits. That also answers the question how to limit an ap, always keep unique names on indexes.

Thank you for your inputs as your comments confirmed my concerns.

View solution in original post

0 Karma

DalJeanis
SplunkTrust
SplunkTrust

If they have different types of data, then you should have different index names and/or different sourcetypes, and you therefore should have no problem at all. The searches will ignore the data that is not relevant to them. That doesn't sound like the behavior that you are experiencing,

0 Karma

jkat54
SplunkTrust
SplunkTrust

Yeah just because the app doesn’t ship with indexes defined doesn’t mean you’re not responsible for creating the indexes, proper sourcetyping, tagging, etc.

These issues are completely avoidable with a proper naming convention and configuration.

0 Karma

kmorris_splunk
Splunk Employee
Splunk Employee

Search restrictions are applied at the role level. I don't believe there is a way to do this. At the role level, you could add a restriction filter specifying the indexers using the splunk_server field, but this will only be for that role. You also have to consider inheritance from other roles a user might have.

0 Karma

sudosplunk
Motivator

Hello,

I don't think this can be achieved at app-level. The restrictions to the data(indexes) are applied at a role level. If you have access to an index, you can search that index data from any app. Is RBAC a considerable option?

0 Karma
Did you miss .conf21 Virtual?

Good news! The event's keynotes and many of its breakout sessions are now available online, and still totally FREE!