App architecture and object ownership

Apps are commonly built from Splunk knowledge objects. Splunk knowledge objects include saved searches, event types, tags -- data types that enrich your Splunk deployment and make it easier to find what you need.

You might save objects to add-ons as well, though this is not common. Apps and add-ons are both stored in the apps directory. In the rare case that you save objects to an add-on, you manage the add-on as described for apps in this topic.

Any user logged into Splunk Web can create and save knowledge objects to the user's directory under the app the user is "in" (assuming that they have sufficient permissions). This is the default behavior. When a user saves an object, it goes into the user's directory in the local directory of the currently running app: $SPLUNK_HOME/etc/users/<user_name>/<app_name>/local. When the user has saved the object in that app, it is available only to that user when they are in that app unless they do one of the following:

• Promote the object so that it is available to all users who have access.
• Restrict the object to specific roles or users (still within the app context).
• Mark the object as globally available to all apps, add-ons, and users (unless they have explicitly restricted it by role/user).

Users must have write permissions for an app or add-on before they can promote objects to that level.

Promote and share Splunk knowledge

Users can share their Splunk knowledge objects with other users through the Permissions dialog. This means users who have read permissions in an app or add-on can see the shared objects and use them. For example, if a user shares a saved search, other users can see that saved search, but only within the app in which the search was created. So if you create a saved search in the app "Fflanda" and share it, other users of Fflanda can see your saved search if they have read permission for Fflanda.

Users with write permission can promote their objects to the app level. This means the objects are copied from their user directory to the app's directory -- from:

$SPLUNK_HOME/etc/users/<user_name>/<app_name>/local/

to:

$SPLUNK_HOME/etc/apps/<app_name>/local/

Users can do this only if they have write permission in the app. For a discussion of app object permissions, and governing access to those objects, see Set app permissions using Splunk Web on the Splunk Developer Portal.

Make Splunk knowledge objects globally available

Finally, after promotion, users can decide if they want their object to be available globally, meaning that all apps are able to see it. The user must have permission to write to the original app. It's easiest to do this in Splunk Web, but a user can also do it later by moving the relevant object into the desired directory.

To make globally available an object "A" (defined in "B.conf") that belongs to user "C" in app "D":

1. Move the stanza defining the object A from $SPLUNK_HOME/etc/users/C/D/B.conf into $SPLUNK_HOME/etc/apps/D/local/B.conf.

2. Add a setting, export = system, to the object A's stanza in the app's local.meta file. If the stanza for that object doesn't already exist, you can just add one.

For example, to promote an event type called "rhallen" created by a user named "fflanda" in the *Nix app so that it is globally available:

1. Move the [rhallen] stanza from $SPLUNK_HOME/etc/users/fflanda/unix/local/eventtypes.conf to $SPLUNK_HOME/etc/apps/unix/local/eventtypes.conf.

2. Add the following stanza:

[eventtypes/rhallen]
export = system

to $SPLUNK_HOME/etc/apps/unix/metadata/local.meta.

Adding the export = system setting to local.meta isn't necessary when you share event types from the Search app, because it exports all of its events globally by default.

What objects does this apply to?

The knowledge objects discussed here are limited to those that are subject to access control. These objects are also known as app-level objects and users can view them by selecting Apps > Manage Apps from the Splunk bar. This page is available to all users to manage any objects they have created and shared. These objects include:

• Saved searches and Reports
• Event types
• Views and dashboards
• Field extractions

There are also system-level objects available only to users with admin privileges (or read/write permissions on the specific objects). These objects include:

• Users
• Roles
• Auth
• Distributed search
• Inputs
• Outputs
• Deployment
• License
• Server settings (for example: host name, port, etc)

If you add an input, Splunk adds that input to the copy of inputs.conf that belongs to the app you're currently in. This means that if you navigated to your app directly from Search, your input will be added to $SPLUNK_HOME/etc/apps/search/local/inputs.conf, which might not be the behavior you desire.

App configuration and knowledge precedence

When you add knowledge to Splunk, it's added in the context of the app you're in when you add it. When Splunk is evaluating configurations and knowledge, it evaluates them in a specific order of precedence, so that you can control what knowledge definitions and configurations are used in what context. Refer to About configuration files for more information about Splunk configuration files and the order of precedence.