Default permissions

By default, the admin and power roles have execute, read, and write permissions on all modules in an app.

When you create a module, as the module owner you are automatically given execute, read, and write permissions to that module. Permissions for the module owner can't be revoked.

When a role is granted access to an app, the role automatically has execute permission on all of the modules in the app. The roles that are assigned to a user determine if the user has other permissions on the modules in the app.

The execute permission enables these users to run the views that are exported from the modules in the app.

• The execute permission enables the role to run a search that is in the module.
• The read permission enables the role to run a search and to see the entire contents of the module, which is also referred to as the module definition. The read permission supersedes the execute permission.
• The write permission enables the role to perform create, update, and delete operations.

Changing module permissions

The module owner, or anyone with write permission on the module, can change the module permissions.

You can modify role-based permissions for SPL2-based apps at the module level by using the permissions API endpoints.

To change module permissions, use these steps:

1. Determine the current permissions for each role on a module. Use the GET request for the services/spl2/permissions/role/{rolename} endpoint. For example:

   curl -k -u admin:pass https://localhost:8089/services/spl2/permissions/role/analyst
   

2. Use the POST request for the services/spl2/permissions endpoint to change the module permissions. For example, suppose the module already has the following permissions defined:

   Operation	Roles
   execute	admin, power, user, analyst
   read	admin, power
   write	admin, power

   To add the analyst role to the read permission, you would specify the following POST request:

   curl -k -u admin:pass https://localhost:8089/services/spl2/permissions \
   --data '{
     "resourceType": "module",
     "resourceName": "my_module",
     "permissions": [
        {
         "operation": "execute",
         "roles": [
           "admin",
           "power",
           "user",
           "analyst"
         ]
       },
       {
         "operation": "read",
         "roles": [
           "admin",
           "power",
           "analyst"
         ]
       },
       {
         "operation": "write",
         "roles": [
           "admin",
           "power"
         ]
       }
     ]
   }'
   

For details on the SPL2 REST endpoints, see Search endpoint descriptions in the Splunk Enterprise REST API Reference Manual.

Run_as_owner: annotation impact on module permissions

Adding the @run_as_owner; annotation to a module changes the module permissions. For more information, see How permissions change when run as owner is enabled later in this topic.

Scenario: Implementing run as owner feature

Here is a scenario that explains how the run as owner feature works:

Sasha, a Splunk administrator, creates or installs an application that contains a module called masked. The masked module imports the main index, which contains sensitive data that should not be accessed by all users. However, Sasha wants all users to access a filtered subset or view of the same data, without double-indexing the masked or filtered data into a separate index.

Alex is a user who doesn't have permissions on the main index. Alex needs access to some of the data on the index, but not to the sensitive data.

Sasha creates an SPL2 search to mask out PII information, such as email addresses, creating a masked view of the data. The view is called masked_main.

Sasha grants Alex execute permission on the masked module. The searches run by Alex using the masked_main view fail because Alex doesn't have permissions on the main index. Even if Sasha grants Alex read and write permission on the masked module, the searches run by Alex will still fail because Alex doesn't have permissions on the underlying dataset, the main index.

To enable Alex to run searches using the views in the masked module, Sasha can enable the run as owner feature. As the owner of the module, Sasha is the only user who can add the @run_as_owner; annotation to the module.

When Sasha adds the @run_as_owner; annotation to the module, Alex can run searches using any of the views in the masked module. Alex can only run searches using Sasha's permissions for the views in the maskedmodule.

Alex can't access the underlying datasets. The views access the underlying datasets.

As the owner of the module, Sasha is also the only user who can delete the module.

Steps: Enable run as owner permissions

By default, the run_as_owner feature is turned off. You can enable users, other than the module owner, to run searches using the views in an SPL2 module.

To turn on the run_as_owner feature, follow these steps.

1. Open the local server.conf file for the Search app. For example, $SPLUNK_HOME/etc/apps/<app_name>/local. If a local server.conf file doesn't exist, create the file.
2. Under the [spl2] stanza, set the run_as_owner_enabled to true.
3. For the module you want to add the annotation to, copy or create the module in the local directory of the application.
4. Edit the module in the app local directory and add @run_as_owner; to the first line in the module.
5. Create the searches to mask or filter out the data you don't want users to access.
6. Save the module and re-install the app. See Install SPL2-based apps.
7. Grant the roles execute permission on the module so that the users can run searches using the views in the module.
8. Ensure the users do not have permissions on the underlying dataset, such as an index. The users will see only the data that is filtered by the view that they use in their search.

How permissions change when run as owner is enabled

When a Splunk administrator installs or creates an SPL2-based application, the administrator becomes the owner of the modules in that application. As the module owner, you have execute, read, and write permissions on the module.

When the @run_as_owner; annotation is added to a module, any user with execute permission can run a search using any item exported by the module. Therefore it is important that the only items exported from the module are the masked or filtered views.

If a user imports a module with this annotation and runs a search, then search quotas are also calculated on the owner's behalf.

Modules marked with the @run_as_owner; annotation can import other modules marked with the annotation only if the modules have the same owner. Imported modules can have a different owner as long as the modules are not marked with the @run_as_owner; annotation.

Only the views exported from the module can be run as the owner of the module. Exported functions are run as the user who imported the function.

Limitations of the run as owner feature

• Splunk Cloud Platform: The sc_admin role does not have the ability to change the run_as_owner_enabled setting in the server.conf file. Additionally, there is no REST API endpoint to change this setting.
• Module permissions: The default module permissions assigned to the admin and power roles do not apply to modules that are marked with the @run_as_owner; annotation. For security reasons, only the owner of those modules retains write permission on the modules. When a module owner adds the @run_as_owner; annotation to a module, the data orchestrator adjusts the permissions on the module. Other users who were granted write permission on that module no longer have that permission on that module. This change in permissions is handled internally by the data orchestrator. Calls to the SPL2 REST endpoints still reflect the permissions granted to users before the @run_as_owner; annotation was added to the module.
• Module ownership inheritance: If a Splunk administrator is removed from the system, there is no ownership inheritance on any of the modules that that administrator owns.

For more information about risky commands: