Accessing Splunk resources

Splunk's layering of resources

Splunk takes a layering approach for access to resources. This layering approach is necessary to account for permissions to view apps, system files, and other resources by users throughout a Splunk installation.

Splunk implements this layering approach through configuration files and an order of precedence that determines access to the resources defined therein.

Splunk REST API endpoints, as described later in this section, provide access to resources based on this layering approach. This is important when viewing, creating, updating, or deleting resources to make sure you are accessing the correct resources for a user's namespace.

For details on Splunk configuration, refer to the Splunk Admin manual, specifically the sections:

Search-time resources (Splunk objects)

Generally speaking, resources that affect search activities have an app/user context. The app/user context defines a namespace that is accessible from the servicesNS endpoints, as described in servicesNS endpoints. Search-time resources are considered objects within a Splunk system.

The order or precedence in the app/user context is:

Settings specific to a user

Settings specific to the current app

Settings globally-visible from other apps

System-wide settings

This layering enables users access to not only resources specific to them but also to apps and system-wide settings.

The order of precedence also accounts for different resources with the same name. For example, a user can have a saved search with the same name as a saved search at the system level.

Examples of search-time resources include:

/saved/searches (saved searches)

/data/props/extractions (field extractions)

Index-time resources (Splunk configurations)

For some resources there is no user/app context. These are resources that affect data input, indexing, or deployment activities. Index-time resources are considered configurations in a Splunk system. These resources are available from namespace endpoints as described in servicesNS endpoints.

For index-time resources, the order of precedence is:

Local system settings

Settings for all apps

Default system settings

Because there is no user/app context, user-specific settings are ignored. Access to resources is based on the capabilities defined in the Splunk-defined role for a user. For example, /data/inputs/monitor looks the same to all users who have access to the resource. Access is based on a user's Splunk role.

Examples of these resources include:

/data/indexes (indexes)

/data/inputs/monitors (monitor inputs)

servicesNS endpoints

When using the Splunk REST API, use the namespace (/servicesNS/* endpoints) to ensure that you specify the correct user/app context for the resource:

wildcards - To specify all users or all apps, use the wildcard, '-'. For example: .../servicesNS/-/-/saved/searches. When using a wildcard for all users, this includes shared application resources accessible by all users.

Search-time resources

For example, from the Splunk default management port, the following GET operation returns saved searches accessible by the admin user from within the search app context. It does not, however, list saved searches private to the admin user in another app, such as the launcher app.

Note: Splunk recommends that you use the servicesNS endpoints, especially for create, update, and delete operations. Using the servicesNS endpoints ensures that you are accessing resources using the correct user/app context.

Thus the following GET operations for returning saved searches are equivalent:

Access control lists for Splunk objects

As discussed in Splunk's layering of resources, Splunk uses a user/app/ context to define namespaces for resources. There is an access control list associated with this context that enforces ownership and permissions for access to the resources. The following table lists the acl properties for Splunk resources.

Note: The acl properties listed here are typically used when developing Splunk applications. Some acl properties, such as can_share_app and modifiable, are reserved for internal use.

acl Property

Description

app

The app context for the resource. Allowed values are:

The name of an app

system

can_list

For internal use only for the Splunk Web manager UI.

can_share_*

Indicates whether the current user can change the entity's sharing state. The sharing state can be app, global, or private.

Applies to:

can_share_app

can_share_global

can_share_user

can_write

Indicates if the current user can edit this item.

owner

The user that owns the resource.

"nobody" means that all users have access to the resource. However, write access to the resource might be restricted.

modifiable

Indicates if the access control list (ACL) is modifiable.

modifiable is set to false for items not controlled by ACLs, such as items under /server/logger.

perms.read

Properties that indicate read permissions of the resource.

perms.write

Properties that indicate write permissions of the resource.

removable

Indicates if an admin or user with necessary permissions can remove the entity.

sharing

Indicates how the resource is shared. Allowed values are:

app: Shared through an app.

global: Shared to all apps.

user: Private to a specific user.

Splunk REST API actions for managing acl properties

Many of the Splunk REST API endpoints can invoke actions that allow you to access and modify access control list (acl) properties of objects. The following actions are available:

Append /acl to an endpoint to access acl properties. Provide parameters to this action to make modifications.

Enter your email address, and someone from the documentation team will respond to you:

Send me a copy of this feedback

Please provide your comments here. Ask a question or make a suggestion.

Feedback submitted, thanks!

You must be logged into splunk.com in order to post comments.
Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic.
If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk,
consider posting a question to Splunkbase Answers.

0
out of 1000 Characters

Your Comment Has Been Posted Above

We use our own and third-party cookies to provide you with a great online experience. We also use these cookies to improve our products and services, support our marketing campaigns, and advertise to you on our website and other websites. Some cookies may continue to collect information after you have left our website.
Learn more (including how to update your settings) here »