Set report permissions
Any report you create is initially private and only available to you. If the capabilities granted to you by your role allow it, you can change the report permissions to share it with others.
- Manage knowledge object permissions in the Knowledge Manager Manual.
- Enabling roles other than power and admin to set permissions and share objects in the Knowledge Manager Manual.
- Permissions for Pivot-based reports. Permissions of reports built from Pivot cannot exceed the permissions of the data models referenced by those reports.
- Determine whether to run reports as the report owner or report user.
- Saving and sharing jobs in Splunk Web in the Search Manual. When you change the permissions of an existing scheduled report, those new permissions apply only to future jobs generated by that scheduled report. You have to change permissions of existing jobs generated by that scheduled report through the job manager.
- Open the Edit Permissions dialog for your report.
There are a number of ways that you can access the Edit Permissions dialog:
Access method For existing reports? Access steps When you first create the report No
- Run a search.
- Save the search as a report.
- On the Your Report Has Been Created dialog, click Permissions.
From the Reports listing page Yes
- Navigate to the Reports listing page.
- Locate the report that you want to edit permissions for.
- Click Edit, and select Permissions.
From the report display view Yes
- Navigate to the Reports listing page.
- Find the name of the report and click it to open the report.
- Click Edit and select Edit permissions.
From Settings Yes
- Navigate to Settings > Searches, Reports, and Alerts.
- Locate the report that needs to have its permissions edited.
- Click its Permissions link.
- Select either App or All apps.
All reports are created in the context of a specific app.
- Select App to share the report with other users of the app that the report belongs to.
- Select All apps to share the report with all users of your Splunk platform implementation.
- (Optional) Determine whether the report runs as Owner or User.
This setting determines whether the search runs with the permissions of the search Owner (the person who defined the search) or the permissions of the search User (the person who is running the search). Reports run as Owner by default.
- Set the Read and Write permissions by role.
Read gives a user with the selected role the ability to see and run the report, but they cannot edit it. Write gives the user the ability to run and edit the report if they wish. If you leave these settings unmarked for a particular role, that role cannot see the report.
- Click Save to save your permissions changes.
Determine whether to run reports as the report owner or report user
When you share a report with other users, you have the option of having it run with the permissions of the report "owner" (the person who created the report) or the report "user" (the person who is running the report). This setting is used for two reasons:
- It can allow access to search data that might otherwise be unavailable to the person running the report.
- It helps prevent situations where your concurrent search limit is reached when too many people run reports that you own.
All reports run as Owner by default.
Scheduled reports and alerts can only run as Owner. If you share a report so that it runs as User and then schedule that report, its permissions change to run as Owner.
The Owner and User settings can also affect the way your users interact with dashboards with panels that are backed by reports. See Working with dashboard panels in Dashboards and Visualizations with Simple XML.
Control access to report results
The Owner and User settings let you control access to the data returned by your reports. For example, say you have an index that is restricted to users with the Admin role. When a person with the Admin role writes a search that accesses events in this index and then shares it as a report that runs as Owner, any user with a lesser role can run it and see the events from the restricted index, because the report runs as if its Admin role owner ran it. This might be the desired outcome, if the Admin user wants to expose certain aspects of otherwise restricted data to users with lesser permissions.
If the Admin shares the report so it runs as User, anyone can run it, but when they do, the report runs with their permissions, not those of the report owner. So if you have the User role and you run the report, the report cannot return events from the restricted index, because your permissions are not as strong as those of the report owner.
Keep concurrent search job limits for report owners from being exceeded
The Owner and User controls determine whether a run of the report counts against the concurrent search job limit of the report "owner" or the report "user." These limits vary by role and are set in Settings > Access controls > Roles > <name of role>. You may want to have a shared report run as User so that your concurrent search limit isn't reached when other users run the report at the same time.
For example, by default, a person with the Admin role can run 50 search jobs concurrently. It is highly unlikely that an Admin user would run more than 50 jobs at the same time, but if they did, any additional jobs would be queued up by the report scheduler to run later.
Now imagine that you have the Admin role. You run a search, save it as a report, and share it to run as Owner. Later, someone else builds a dashboard and uses your report to back one of the panels. If this dashboard is especially popular, you could run into a situation where you find that your concurrent search limit is constantly being hit because that dashboard is loaded or reloaded by large numbers of users. To solve this problem you would edit the permissions for the report so that it runs as User.
Permissions for Pivot-based reports
Permissions for reports built in Pivot cannot exceed those of the data model that the report references. For example, you cannot share a report to users of all apps if it references a private data model. If you try to do this you will receive an error message. You must first share the data model referenced by the report to users of all apps, and then set the report permissions accordingly. For more information about sharing data models, see Manage data models in the Knowledge Manager Manual.
Here is a slightly more complex example. Your Splunk deployment has two apps installed: Search and Security. When you are in the context of the Security app, you use its External Threats data model to create a Pivot-based report titled "Top Firewall Attacks by IP." The External Threats data model has permissions that are scoped to the Security app, and nothing more.
When you first create the report, its permissions are set to Owner, which means that you are the only person who can see the report and update it. You want everyone to see the "Top Firewall Attacks by IP" report, regardless of app context, so you change its permissions to All apps. Now, when you switch your app context to the Search app, you might expect to be able to access "Top Firewall Attacks by IP" from the Search app.
However, you cannot view it from the Search app. This is because the report is based on the External Threats data model, and that data model's permissions are still scoped to the Security app. To access and run the "Top Firewall Threats by IP" report from the Search app, share the External Threats data model globally by setting its permissions to All apps.
Create and edit reports
This documentation applies to the following versions of Splunk® Enterprise: 6.5.7, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10, 8.1.0, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.10, 8.1.11, 8.1.12, 8.1.13, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 7.3.9, 8.0.0, 8.0.1
Feedback submitted, thanks!