Restricting Access Using the Search Filter Generator: Drawbacks and Limitations
By: Nate Hufnagel | Splunk Consultant
Role-Based Access Control, or RBAC, is the paradigm for restricting access to authorized users in Splunk. These practices are commonly used to limit what data is visible to end users, depending on their role in an organization. Within Splunk, an admin has precise control over what privileges a user has, from searching data from particular indexes, to what alert actions they can create and also to what knowledge objects they can edit as well as many other Splunk behaviors. With search filters, you can get even more granular with what information a user can see. These are custom searches that get processed before each user’s search query that “filter” which results a certain user can see. While this method can be useful for giving access to specific data within an index, it is not the most efficient way to segregate data. Furthermore, it is not recommended as the best way to control who sees what in any Splunk deployment. Here we’ll explore why restricting access using the search filter generator doesn’t always work as we’d expect.
User Privileges in the Splunk Web UI (Enterprise or Cloud)
Before diving into the search filter mechanics, let’s look at its context in defining user privileges. There are 5 categories within the web UI that determine a users’ privileges: inheritance, capabilities, indexes, restrictions, and resources. These can be found by navigating to Settings>Roles and clicking on a role name.
1. Inheritance
a. Where a new role type can be given the same capabilities of another. Here you can select from previously created roles and “inherit” their capabilities for a new role.
2. Capabilities
a. Where an admin can select what specific capabilities a role has, like edit_https or run_debug_commands to name a few. This affords very granular control over what a certain user can do within Splunk.
3. Indexes
a. Defines what indexes are searchable to a user. Restricting access on an index basis is a best practice in Splunk and should be the primary way to implement RBAC. Here and admin can also set what indexes a user can search by default when one is not explicitly defined in a search.
4. Restrictions
a. This is where the search filter lives. Here, there are two options for creating a search filter: by using the search filter generator, or by typing directly into the search filter. We will explore these functions in more detail later.
5. Resources
a. Here, an admin can set resources usage limitations for a role. This can include only allowing searches within a certain app, restricting the number of search jobs a role can run at the same time, even the amount of disk space a search job can use.
Now that we have some context, lets dive into the search filter behavior, and why it doesn’t always work as expected. Here we can see the search filter as it appears in Splunk:
On the left of the screen, we see the search filter generator. As the name suggests, this tool pulls indexed fields and there values and creates a filter that get appended to any search run by a user assigned to the role. At the top, there is a drop down option that controls how long Splunk will spend looking for a certain field or value. By default, the search filter is populated with a wildcard. We can preview what information this role can see by clicking “Preview search filter results”:
By default, users can see all fields and indexes visible to them as defined by their role. Next, let’s try and filter events a little further by excluding results where sourcetype=splunkd. We’ll start by deleting the wildcard “*” in the search filter.
In this example, we type “sourcetype” into the Indexed fields box, then “splunkd” into the “Values” box. Concatenation is greyed out here because the search filter is currently empty. Clicking “Add to search filter” adds our newly created filter as (sourcetype::splunkd). But how can we know if the filter we created works as expected?
We can preview what information this role can see by clicking Preview search filter results.
As expected, only events with a source type of splunkd are returned. To exclude events with the same settings, add NOT to the beginning of the filter.
There are some drawbacks to using an SPL filter this way. The results that come back to a user can depend on multiple factors and aren’t always what you’d expect. Here are a few caveats to keep in mind when using the search filter, and why it should generally be avoided:
1. Using the search filter generator alone can create inefficient SPLs
a. Let’s take another look at the example above. If we wanted to exclude splunkd events from a specific source using the search filter generator, we would append the previous filter using the same method as before:
The results come back as expected, however using multiple NOT statements in this manner is inefficient and could cause serious performance issues.
2. Roles can inherit index restrictions and capabilities from other roles, but not their search filters
a. For example, lets say our standard power user role had some search restrictions assigned to it. If we wanted to create another power user role that inherited power user privileges and some additional capabilities (but maintain the search filter), we would need to copy the search filter and apply it to the new role.
3. Certain configurations in authorize.conf can alter how a search filter behaves
a. Within authorize.conf, there is a parameter called “srchFilterSelecting” that controls how the search filter behaves. It is set to true by default at a global level, which means that search filters select the results the user sees. If set to false, it eliminates the results. This can cause confusion even in a simple environment, especially if different apps assume one setting or another.
b. In the examples above, we executed our search filters with the default setting of srchFilterSelecting=true. If we set it to false, all of our filters would behave the opposite of what is expected. So even though we successfully excluded certain events using a NOT statement, Splunk would now interpret the opposite of this statement and only include the results of our search filter.
4. The search filter only works on indexed fields
a. Any fields that are extracted at search time will not be effective in the search filter, even if they are entered manually. This limits the flexibility of the search filter, and presents an issues with no clear workaround. We could move some search-time extractions to index-time however this is not feasible in the long term, as having too many index-time field extractions can negatively impact indexer performance.
There are better solutions when it comes to creating scalable role-based access controls in Splunk. The following documents outline when and how to implement these restrictions in detail and includes some common use cases for handling sensitive data in Splunk.