Splunk Search

Role Based filtering to mask JWT tokens and Emails

sabbas
Explorer

Hello folks,

We use Splunk cloud platform for our logging system. I was trying to use the Search Filter under the Restrictions tab in Edit Role to add a filter which masks JWT tokens and emails in a search but keep running into an error with the litsearch command: unbalanced parenthesis.

Regex used in the search filter:

| eval _raw=replace(_raw, "token=([A-Za-z0-9-]+\.[A-Za-z0-9-]+\.[A-Za-z0-9-_]+)", "token=xxx.xxx.xxx")
| eval _raw=replace(_raw, "[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}", "xxx@xxx.xxx")

When a user with the role that has the restriction above tries to search for anything the job inspector shows that there are parenthesis around the literal search and the search filter above so it would look like this

litsearch (<search terms> | eval _raw....)

I tried changing the search filter to be 

| rex mode=sed "s/token=([A-Za-z0-9-]+\.[A-Za-z0-9-]+\.[A-Za-z0-9-_]+)/token=xxx.xxx.xxx/g"

to only replace the tokens but still run into the same issue. When previewing the filter the results work fine, but when doing an actual query with the user it will fail.

Any suggestions to make the search filter simpler, or any other methods I could use for role based search filtering?

Labels (3)
0 Karma
1 Solution

livehybrid
SplunkTrust
SplunkTrust

Hi @sabbas 

The Search Filter feature in Splunk roles is designed to restrict which events a user can search, not to transform or mask the data within those events.

The syntax error "unbalanced parenthesis" occurs because the commands | eval or | rex mode=sed are pipeline commands. When you place them in the Search Filter, Splunk attempts to insert them into the initial search command (like litsearch or search) in a way that breaks the expected syntax, as pipeline commands cannot directly follow search terms within the initial command's arguments.

Search Filters should contain search clauses that filter events, such as index=myindex, sourcetype=mysourcetype, or boolean combinations of these. They are applied before the user's search string is fully processed as an SPL pipeline.

Modifying the _raw field based on user roles at search time is a complex requirement that is not directly supported by the standard role configuration's Search Filter.

The typical Splunk method for masking sensitive data is done at index time using props.conf and transforms.conf. This is the most secure method as the data is masked before being written to disk, but it applies globally and is not role-specific. Implementing role-based masking at search time usually requires more advanced techniques, potentially involving custom search commands or complex logic applied via views or macros, which is beyond the scope of a simple role filter.

  • Search Filters are for restricting events (e.g., index=sales), not transforming data (| eval, | rex).
  • Placing pipeline commands (|) in the Search Filter string will cause syntax errors.
  • Role-based data masking at search time is not a standard feature of role configurations.

The search filter configuration page within Splunk states:

The search filter can only include:

  • source type
  • source
  • host
  • index
  • event type
  • search fields
  • the operators "*", "OR", "AND", "NOT"

See Anonymize data for more ideas too.

🌟 Did this answer help you? If so, please consider:

  • Adding karma to show it was useful
  • Marking it as the solution if it resolved your issue
  • Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

View solution in original post

livehybrid
SplunkTrust
SplunkTrust

Hi @sabbas 

The Search Filter feature in Splunk roles is designed to restrict which events a user can search, not to transform or mask the data within those events.

The syntax error "unbalanced parenthesis" occurs because the commands | eval or | rex mode=sed are pipeline commands. When you place them in the Search Filter, Splunk attempts to insert them into the initial search command (like litsearch or search) in a way that breaks the expected syntax, as pipeline commands cannot directly follow search terms within the initial command's arguments.

Search Filters should contain search clauses that filter events, such as index=myindex, sourcetype=mysourcetype, or boolean combinations of these. They are applied before the user's search string is fully processed as an SPL pipeline.

Modifying the _raw field based on user roles at search time is a complex requirement that is not directly supported by the standard role configuration's Search Filter.

The typical Splunk method for masking sensitive data is done at index time using props.conf and transforms.conf. This is the most secure method as the data is masked before being written to disk, but it applies globally and is not role-specific. Implementing role-based masking at search time usually requires more advanced techniques, potentially involving custom search commands or complex logic applied via views or macros, which is beyond the scope of a simple role filter.

  • Search Filters are for restricting events (e.g., index=sales), not transforming data (| eval, | rex).
  • Placing pipeline commands (|) in the Search Filter string will cause syntax errors.
  • Role-based data masking at search time is not a standard feature of role configurations.

The search filter configuration page within Splunk states:

The search filter can only include:

  • source type
  • source
  • host
  • index
  • event type
  • search fields
  • the operators "*", "OR", "AND", "NOT"

See Anonymize data for more ideas too.

🌟 Did this answer help you? If so, please consider:

  • Adding karma to show it was useful
  • Marking it as the solution if it resolved your issue
  • Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

Career Survey
First 500 qualified respondents will receive a $20 gift card! Tell us about your professional Splunk journey.

Can’t make it to .conf25? Join us online!

Get Updates on the Splunk Community!

Community Content Calendar, September edition

Welcome to another insightful post from our Community Content Calendar! We're thrilled to continue bringing ...

Splunkbase Unveils New App Listing Management Public Preview

Splunkbase Unveils New App Listing Management Public PreviewWe're thrilled to announce the public preview of ...

Leveraging Automated Threat Analysis Across the Splunk Ecosystem

Are you leveraging automation to its fullest potential in your threat detection strategy?Our upcoming Security ...