Configure how capabilities grant access to Splunk resources and workflows with authorization policies

Authorization policies give you better control on how Splunk capabilities let your users access Splunk resources.

The Splunk authorization model is a hybrid configuration, where Splunk roles determine access to some Splunk objects, and capabilities limit access to other objects through access control lists. Capabilities control access to global objects that do not have user or application namespaces. Authorization policies, also known as scoped capabilities, extend the authorization models of these capabilities by giving you finer-grained control on how capabilities let Splunk users access Splunk resources.

How authorization policies work to limit the scope of capabilities

In general, Splunk capabilities are additive in nature, which means that you can never use a capability to take access to a Splunk resource or workflow away. If you don't want a Splunk user to have access to something, you must not assign that user the capability that grants access to that thing. Currently, if you give a Splunk user access to a role that has that capability, the user gets access to the resource through the capability. You must create a separate role without the capability if you don't want the user to have access to that resource.

Authorization policies give you finer control on what kinds of things to which a capability gives access. Capabilities still give access to resources and workflows, and while that doesn't change, you can now control the conditions by which the capability grants access to the resource.

Authorization policies work on the Splunk platform by providing certain conditions that must exist prior to the Splunk platform allowing access to a resource or workflow. Given the following example role, as depicted in the authorize.conf configuration file:
[role_user]
indexes_edit = enabled 
edit_restmap = enabled
edit_local_apps = disabled
The indexes_edit and edit_restmap capabilities explicitly grant this role access to the ability to make changes to index configurations and edit the REST map configuration. The edit_local_apps capability is explicitly configured as disabled, which prevents the role from making changes to the local app configurations on the instance. Access to all other resources and workflows is not available for this role.
In a scenario with authorization policies in effect, you could have a configuration as follows:
[role_user]
indexes_edit = user_indexes_only 
edit_restmap = enabled
edit_local_apps = disabled

[policy::user_indexes_only]
access = {
	"allow": {
		"conditions": [ {
			"operation": "oneOf",
			"attr": "entity::name",
			"values": [ "main","user_index1","user_index2" ]
			} ]
		}
	}
In this example, the role_user role still has access to edit the REST map configuration through the edit_restmap capability, and still does not have the ability to edit local application configurations because the capability is explicitly inactive, nor does it have access to any other platform resources or workflows. But its access to make changes to indexes has been significantly reduced in scope.

Here, the value user_indexes_only refers to what is known as a policy, which is a block of JavaScript Object Notation (JSON) code that defines the scope in which the indexes_edit capability gives the role access to index editing. In this case, holders of this role can only edit the "main", "user_index1", and "user_index2" indexes. All other indexes are read-only to Splunk users that have this role assigned to them.

You can create new Splunk capabilities that limit scope in what users can access, or edit existing capabilities to add policies that limit the scope of their authorization reach. You can then create or update existing roles with these modified capabilities to better control what Splunk users can access.

Next steps