Manage knowledge object permissions

This topic assumes that as a knowledge manager your Splunk account holds a role with the capabilities needed to manage knowledge objects.

As a Knowledge Manager, you can set knowledge object permissions to restrict or expand access to the variety of knowledge objects in your Splunk deployment.

In some cases you will determine that certain specialized knowledge objects should only be used by people in a particular role, within a specific app. In others you will make universally useful knowledge objects globally available to users in all apps in your Splunk platform implementation. As with all aspects of knowledge management, you want to carefully consider the implications of the access restrictions and expansions that you enact.

When a Splunk user first creates a new report, event type, transaction, or similar knowledge object, it is only available to that user. To make that object available to more people, Splunk Web provides the following options, which you can take advantage of if your permissions let you do so. You can:

• Make the knowledge object available globally to all users of all apps (also referred to as "promoting" an object).
• Make the knowledge object available to all roles associated with an app.
• Restrict (or expand) access to global or app-specific knowledge objects by role.
• Set read/write permissions at the app level for roles, to enable users to share or delete knowledge objects they do not own.

By default, only people 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.

Users with the "admin" role can change permissions for any knowledge object. Users with the "power" role can change permissions for the objects that they own. New for version 9.3.2411 of Splunk Cloud Platform, there are new capabilities that you can assign to roles for the management of saved searches that replace the admin_all_objects capability and potentially remove the need for using the "admin" and "power" roles for the management of saved searches.

For information about giving roles other than "admin" and "power" the ability to set knowledge object permissions, see Enable a role other than 'admin' and 'power' to set permissions and share objects.

How do permissions affect knowledge object usage?

To illustrate how these choices can affect usage of a knowledge object, imagine that Finn, 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:

Issue	Action	Result
When Finn first creates firewallbreach, it is only available to Finn. Other users can neither see it nor work with it. Finn decides to share it with their fellow Network Security app users.	Finn updates the permissions of the firewallbreach event type so that it is available to all users of the Network Security app, regardless of role. They also set up the new event type so that all Network Security users can edit its definition.	Anyone using Splunk Enterprise in the Network Security app context can see, work with, and edit the firewallbreach event type. Users of other apps in the same Splunk Enterprise deployment have no idea it exists.
A bit later on, Mary, the knowledge manager, realizes that only people with the Firewall Manager role should have the ability to edit or update the firewallbreach event type.	Mary restricts the ability to edit the event type to the Firewall Manager role.	Users of the Network Security app can use the firewallbreach event type in transactions, searches, dashboards, and so on, but now the only people that can edit the knowledge object are those with the Firewall Manager role and people with admin-level permissions (such as the knowledge manager). Splunk users in other app contexts remain unaware of the event type.
At some point a few people who have grown used to using the firewallbreach event type in the Network Security app decide they would also like to use it in the context of the Windows app.	They make their case to the knowledge manager, who promptly promotes the firewallbreach event type to global availability.	Now, everyone that uses this Splunk Enterprise deployment can use the firewallbreach event type, no matter what app context they happen to be in. But the ability to update the event type definition is still confined to admin-level users and users with the Firewall Manager role.

Get started with changing knowledge object permissions

To change the permissions for a knowledge object, follow these steps:

1. In Splunk Web, navigate to the page for the type of knowledge object that you want to update permissions for.
2. Find the knowledge object that you created (use the filtering fields at the top of the page if necessary) and open its permissions dialog.
   
   • In some cases you will need to click a Permissions link to do this. In other cases you need to make a menu selection such as Edit > Edit Permissions or Manage > Edit Permissions.
   • If you are on a listing page you can also expand the object row and click Edit for Permissions.
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.
4. Click Save to save your changes.

Make an object available to users of all apps

To make an object globally available to users of all apps in your Splunk deployment:

1. Navigate to the Permissions page for the knowledge object (following the instructions above).
2. For Display for, select All apps.
3. In the Permissions section, for Everyone, select a permission of either Read or Write.
   

   Option	Definition
   Read	When this is selected for a role, people with the role can see and use the object, but not update its definition. For example, when a role only has Read permission for a report, people with that role can see the report in the Reports listing page and they can run it. They cannot update the report's search string, change its time range, or save their changes.
   Write	When this is selected for a role, people with the role can view, use, and update the defining details of the knowledge object as necessary.

   If neither Read or Write is selected for a role, people with that role cannot see or use the knowledge object.
4. Save the permission change.

Make an object available to all users of its app

All knowledge objects are associated with an app. When you create a new knowledge object, it is associated with the app context that you are in at the time. In other words, if you are using the Search & Reporting app when you create the object, the object will be listed in Settings with Search & Reporting as its App column value. This means that if you restrict its sharing permissions to the app level it will only be available to users of the Search & Reporting app.

When you create a new object, you are given the option of keeping it private, sharing it with users of the app that you're currently using, or sharing it globally with all users. Opt to make the app available to "this app only" to restrict its usage to users of that app, when they are in that app context.

If you have write permissions for an object that already exists, you can change its permissions so that it is only available to users of its app by following these steps.

1. Navigate to the Permissions page for the knowledge object (following the instructions in "Permissions - Getting Started," above).
2. For Display for, select App.
3. In the Permissions section, for Everyone, select a permission of either Read or Write.
   

   Option	Definition
   Read	When this is selected for a role, people with that role can see and use the object, but not update its definition. For example, when a role only has Read permission for a report, people with that role can see the report in the Reports listing page and they can run it. They cannot update the report's search string, change its time range, or save their changes.
   Write	When this is selected for a role, people with the role can view, use, and update the defining details of the knowledge object as necessary.

   If neither Read or Write is selected for a role, people with that role cannot see or use the knowledge object.
4. Save the permission change.

Move or clone a knowledge object

You may run into situations where you want users of an app to be able to access a particular knowledge object that belongs to a different app, but you do not want to share that object globally with all apps. There are two ways you can do this: by cloning the object, or by moving it.

Option	Definition
Clone	Make a copy of a knowledge object. The copy has all of the same settings as the original object, which you can keep or modify. You can keep it in the same app as the object you're cloning, or you can put it in a new app. If you add the cloned object to the same app as the original, give it a different name. You can keep the original name if you add the object to an app that doesn't have a knowledge object of the same type with that name. You can clone any object, even if your role does not have write permissions for it.
Move	Move an existing knowledge object to another app. Removes the object from its current app and places it in an app that you determine. Once there, you can set its permissions so that it is private, globally available, or only available to users of that app. The ability to move an app is connected to the same permissions that determine whether you can delete an app. You can only move a knowledge object if you have created that object and have write permissions for the app to which it belongs. Switching the app context of an knowledge object by moving it can have downstream consequences for objects that have been associated with it. See Disable or delete knowledge objects.

You can find the Clone and Move controls on the Settings pages for various knowledge object types. To clone or move an object, find the object in its list and click Clone or Move.

Restrict knowledge object access by app and 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 Splunk Web, 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).

See About role-based user access in Securing Splunk Enterprise.

Enable a role other than admin and power to set permissions and share objects

By default, only the admin and power roles can set permissions for knowledge objects. Follow these steps to give another role the ability to set knowledge object permissions. This allows a user who has this role to set permissions for the knowledge objects that they own. Only a user with the admin role can change permissions for knowledge objects that are owned by another user.

The ability to set permissions for knowledge objects is controlled at the app level. It is not connected to a role capability like other actions such as scheduling searches or changing default input settings. You have to give roles write permissions to an app to enable people with those roles to manage the permissions of knowledge objects created in the context of that app.

Steps

1. From the Splunk Home page, select any app in the Apps Panel to open the app.
2. Click on the Applications menu in the Splunk bar, and select Manage Apps.
3. Find the app that you want to adjust permissions for and open its Permissions settings.
4. On the Permissions page for the app, give the role Read and Write permissions.
5. Click Save to save your changes.

Users whose roles have write permissions to an app can also delete knowledge objects that are associated with that app. For more information, see Disable or delete knowledge objects.

Configure roles for fine-grained management of saved search objects, owners, and properties

New for Splunk Cloud Platform, there are new capabilities that allow for improved management of saved search objects, owners, and properties.

The three new capabilities, edit_saved_search, edit_saved_search_owner, and list_saved_search, let administrators more precisely control who can make changes to these knowledge objects. You can use them in the place of the admin_all_objects capability, which was previously required to make changes to saved search properties and owners. They override existing access control lists (ACLs) for saved searches, which means that users who hold these capabilities do not need roles that have read or write capabilities to the saved searches or their properties or owners.

Where applicable, use these new capabilities for managing roles that have access to saved search objects, owners, and properties, rather than the admin_all_objects capability.

The following table describes what the new capabilities do and how you can use them to grant permissions for managing saved searches.

Capability	Description
edit_saved_search	Lets a user change the search string, description, earliest time, and latest time of a saved search without having explicit write permissions for the saved search. To change these fields for any saved search regardless of the access control list (ACL) on that search, the user must hold a role with the list_saved_searches capability.
edit_saved_search_owner	Lets a user change the owner of a saved search that is visible to the user. To change the owner of any saved search regardless of the access control list (ACL) on that search, the user must hold a role with the list_saved_searches capability. To let users change saved search owners in Splunk Web, combine this capability with the list_all_users capability. This capability does not remove the need to recreate a user that has been deleted to reassign an orphaned knowledge object. You must still perform that task, as described in About deleting users who own knowledge objects later in this topic. It is possible for a user with a role that contains this capability to take ownership of a saved search and thus control all properties of the search. They can also reassign a saved search to another user and have the search run as that user.
list_saved_search	Lets a user discover all of the saved searches on the instance. Consequently, lets a user see any active user that owns and any app that contains a saved search, regardless of the ACL permissions on that search.

After you assign these capabilities to a role, you can then assign the role to users to give them the ability to see all saved searches on the system, edit saved search properties, or change the saved search owner. As an admin, you no longer require giving a user the admin or power roles to manage saved search objects, owners, or permissions.

Set permissions for categories of knowledge objects

You can set role-based permissions for specific knowledge object types by making changes to the default.meta file. For example, you can give all user roles the ability to set permissions for all saved searches in a specific app.

See Set permissions for objects in a Splunk App on the Splunk Developer Portal.

About deleting users who own knowledge objects

If you delete a user from your Splunk deployment, the objects that user owns become orphaned. Orphaned objects can have serious implications. For example, when a scheduled report or alert becomes orphaned, it ceases to run on its schedule. When this happens, your team can miss important alerts, actions that are tied to affected scheduled reports will cease to function, and any dashboard panels that are associated with affected scheduled reports will stop showing search results.

To prevent this from happening, reassign knowledge objects to another user. For more information see Manage orphaned knowledge objects.