Scenario: Let's say I have a single index (e.g., main) containing data of interest to multiple different parties/roles, and it is understood that Role1 should only see all data with type=t1 in it, Role2 should only see type=t2, and Role3 only type=t3, etc.
For Role1, if I set my restrictions to the following:
And a user creates a calculated field with the following definition:
This user will be able to see results for all of index=main, since the user's search-time extraction of type=t1 will now be true for all sources.
Question: How do I securely restrict search terms such that it cannot be circumvented by the user's search-time knowledge objects, like calculated fields?
Related post (but I find the answer is not secure):
An index is the entity on which the security framework of Splunk is being built. Therefore, maybe you can find out whether this single index which needs to be shared, can be broken down to multiple indexes and build it from there.
I don't disagree with your comment. My biggest concern is that the Restrict search terms feature is not clearly displayed as insecure if leveraging search-time fields, and I have not seen a Splunk Answers post or Splunk Documentation that clearly warns against using this feature with search-time fields.
Also, I would look to separate this data into distinct indexes if I could, but many times it's not easily separated out at the source. You could use a transform to route the data, but it adds a performance hit to the indexers. Also, if there is overlap in what Role1 should see with what Role2 should see, such as network communications, there is no easy way to do this without using this feature. One could use summary indexing, but then that transforms the original data and default fields, it requires more storage, and it leaves the potential for gaps if the scheduled searches are skipped.
Use of the Restrict search terms feature on a role definition should be limited to the following:
I have only found index to be the only indexed field where you don't need the indexed-field notation, where as default fields like host, source, and sourcetype can take on a user-defined calculated field.
As a user, you can easily spot if your searches are being filtered using this method by running a search, such as index=*, and click Job > Inspect Job, click Search job properties, and identify potential search-time fields within remoteSearch.