Manage knowledge object permissions
Note: This topic assumes that as a knowledge manager you have an admin role or a role with an equivalent permission set.
As a Knowledge Manager, you can set knowledge object permissions to restrict or expand access to the variety of knowledge objects within your Splunk implementation.
In some cases you'll determine that certain specialized knowledge objects should only be used by people in a particular role, within a specific app. And in others you'll move to the other side of the scale and make universally useful knowledge objects globally available to all users in all apps. As with all aspects of knowledge management you'll want to carefully consider the implications of these access restrictions and expansions.
When a Splunk user first creates a new saved search, event type, transaction, or similar knowledge object, it is only available to that user. To make that object available to more people, Manager provides the following options, which you can take advantage of if your permissions enable you to do so. You can:
- Make the knowledge object available globally to users of all apps (also referred to as "promoting" an object).
- Make the knowledge object available to all users of an app.
- Restrict (or expand) access to global or app-specific objects by user or role.
- Set read/write permissions at the app level for roles, to enable users to share or delete objects they do not own.
By default, only users with a power or admin role can share and promote knowledge objects. This makes you and your fellow knowledge managers gatekeepers with approval capability over the sharing of new knowledge objects.
For more information about extending the ability to set permissions to other roles, see the subtopic "Enabling roles other than power and admin to set permissions and share objects," below.
How do permissions affect knowledge object usage?
To illustrate how these choices can affect usage of a knowledge object, imagine that Bob, a user of a (fictional) Network Security app with an admin-level "Firewall Manager" role, creates a new event type named
firewallbreach, which finds events that indicate firewall breaches. Here's a series of permissions-related issues that could come up, and the actions and results that would follow:
|When Bob first creates
||Bob updates the permissions of the
||Anyone using Splunk in the Network Security app context can see, work with, and edit the |
|A bit later on, Mary, the knowledge manager, realizes that only users in the Firewall Manager role should have the ability to edit or update the
||Mary restricts the ability to edit the event type to the Firewall Manager role.||Users of the Network Security app can use the |
|At some point a few people who have grown used to using the very handy
||They make their case to the knowledge manager, who promptly promotes the
||Now, everyone that uses this implementation of Splunk can use the |
Permissions - Getting started
To change the permissions for a knowledge object, follow these steps:
1. In Manager, navigate to the page for the type of knowledge object that you want to update permissions for (such as Searches and reports or Event types).
2. Find the knowledge object that you created (use the filtering fields at the top of the page if necessary) and click its Permissions link.
3. On the Permissions page for the knowledge object in question, perform the actions in the following subsections depending on how you'd like to change the object's permissions.
Make an object available to users of all apps
To make an object globally available to users of all apps in your Splunk implementation:
1. Navigate to the Permissions page for the knowledge object (following the instructions above).
2. Under [Knowledge object type] should appear in:, select All apps.
3. In the Permissions section, for Everyone, select a permission of either Read or Write:
- Read enables users to see and use the object, but not update its definition. In other words, when users only have Read permission for a particular saved search, they can see it in the top level navigation (the "Searches & Reports" dropdown, for example) and they can run it. But they can't update the search string, change its time range, and save their changes.
- Write enables users to view, use, and update the defining details of an object as necessary.
- If neither Read or Write is selected then users cannot see or use the knowledge object.
4. Save the permission change.
Make an object available to users of a particular app
To restrict the usage of a knowledge object to a specific app, you first have to be in the context of that app. To do this, click the App dropdown in the upper right-hand corner of the screen and select the app to which you'd like to restrict the knowledge object.
- If the knowledge object is private, or shared globally, then all you have to do is navigate to the Permissions page for that object and select This app under [Knowledge object type] should appear in:. Then select a permission of either Read or Write for Everyone as appropriate.
- If usage of a knowledge object is already restricted to an app and you want to switch its context to another app, click the Move link (it will only appear if you have sufficient permissions to move it). This will enable you to quickly and easily choose another app context for the knowledge object.
- Keep in mind, however, that switching the app context of an knowledge object can have downstream consequences for objects that have been associated with it. For more information see "Disable or delete knowledge objects," in this manual.
Restrict knowledge object access by role
You can use this method to lock down various knowledge objects from alteration by specific roles. You can arrange things so users in a particular role can use the knowledge object but not update it--or you can set it up so those users cannot see the object at all. In the latter case, the object will not show up for them in Manager, and they will not find any results when they search on it.
If you want restrict the ability to see or update a knowledge object by role, simply navigate to the Permissions page for the object. If you want members of a role to:
- Be able to use the object and update its definition, give that role Read and Write access.
- Be able to use the object but be unable to update it, give that role Read access only (and make sure that Write is unchecked for the Everyone role).
- Be unable to see or use the knowledge object at all, leave Read and Write unchecked for that role (and unchecked for the Everyone role as well).
For more information about role-based permissions in Splunk see "About role-based user access" in the Security manual.
When you use Splunk as delivered the only roles that can set permissions for knowledge objects are power and admin. If you want to grant other roles the ability to set permissions for knowledge objects, navigate to Manager > Apps and click Permissions for a specific app to go to its Permissions page. On this page you can determine which roles have read or write access to the knowledge objects that the app contains. Grant a role write access if you wish for it to have full ability to set knowledge object permissions, including the ability to share searches, alerts, and dashboards when these things are created via Splunk Web.
The ability to set permissions for knowledge objects share knowledge objects is controlled at the app level--it is not connected to a capability like other actions such as scheduling searches or changing default input settings.
For detailed information about enabling roles to set permissions for knowledge objects within apps, see "Step 5: Set Permissions" in the Developing Dashboards, Forms, and Views for Splunk Web Manual.
If a Splunk user leaves your team and you need to delete that user or role from the Splunk system, be aware that you will lose any knowledge objects belonging to them that have a sharing status of private. If you want to keep those knowledge objects, share them at the app or global level before deleting the user or role.
Understand and use the Common Information Model
Disable or delete knowledge objects
This documentation applies to the following versions of Splunk® Enterprise: 5.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4, 5.0.5, 5.0.6, 5.0.7, 5.0.8, 5.0.9, 5.0.10, 5.0.11, 5.0.12, 5.0.13, 5.0.14, 5.0.15, 5.0.16, 5.0.17, 5.0.18