Security models for Federated Search for Splunk

A service account activates different security models depending on whether your federated provider uses standard or transparent mode.

Federated provider mode Security model
Standard mode The role-based access control permissions for the service account user on the federated provider determine what your local users can search on the federated provider.
In addition, access to federated indexes is based on the roles of your local users, which allows you to restrict your local users' ability to search remote datasets on the federated provider. See Give your users role-based access control of federated indexes.
Transparent mode

The role-based access control (RBAC) permissions for your local users help determine what those users can search on the federated provider. However, local RBAC permissions are not enough to grant access to remote indexes on the remote search head.

For a transparent mode federated search to access a remote index, permissions must be configured in the following places:

  • On the local federated search head, the role assigned to the local user who runs the search must include permission to search the index.
  • On the remote search head, the role assigned to the federated provider service account must include permission to search the corresponding remote index.
  • On the remote search head, the role assigned to the federated provider service account must also have the fsh_manage capability. This capability activates transparent mode federated search capabilities for the federated provider.
For example, if a local user runs a transparent mode federated search against index=web_access, the user’s role on the local federated search head must allow searches of index=web_access. On the remote search head, the federated provider service account’s role must have the fsh_manage capability and allow searches of index=web_access. These permission and capability checks validate that both the local and remote search heads allow the local user to access the remote data through transparent mode federated search.

For more information about the standard and transparent federated provider modes, see About Federated Search for Splunk.

Remote index access requirements for transparent mode federated search

For transparent federated searches, access to remote indexes is controlled by role-based access control (RBAC) through both the user’s role on the federated search head and the remote federated provider service account.

To determine whether a user has permission to access a remote index, Splunk checks access in two places:

  • On the remote search head, the federated provider service account must exist and must have access to the remote index.
  • On the local federated search head, the user’s role must allow access to the same index name. In Splunk Web, this means that the Included setting on the Indexes tab for the user’s role must include the name of the remote index that the transparent search targets.

If the remote index name is not included in the user’s role on the federated search head, a user with a low-privilege role can’t access that remote index through transparent mode federated search. This can happen when the index exists on the remote search head, but an index with the same name doesn’t exist on the federated search head. In that case, the index might not appear in the list of indexes on the role’s Indexes tab on the local federated search head. That means that an administrator can’t select the index in Splunk Web, in order to add it to the Included setting for the user’s role.

Users with the admin role are not restricted in the same way, because the admin role can access all indexes in the deployment. As a result, an admin user can run a transparent mode federated search against a remote index even if an index with the same name does not exist locally on the federated search head.

For low-privilege users, if the remote index does not exist locally on the federated search head, an administrator can create a local placeholder index on the federated search head with the same name as the index on the remote search head. The placeholder index does not need to contain data. Its purpose is to make the index name available on the federated search head so that the administrator can add it to the Included setting for the role in Splunk Web. After the index name is included in the user’s role on the local federated search head, and the federated provider service account has access to the index on the remote search head, the low-privilege user can run transparent mode federated searches against that remote index.

For example, suppose the finance index exists on the remote search head, but a finance index doesn’t exist on the local federated search head. If you want a low-privilege user to run transparent mode federated searches such as index=finance, create an empty placeholder index named finance on the federated search head. Then update the user’s role on the federated search head so that finance appears in the Included setting on the Indexes tab for that role. Also make sure that the federated provider service account on the remote search head has access to the finance index. After both conditions are met, the user can search the remote finance index through transparent mode federated search.

Note:

Creating a placeholder index is primarily a workaround for configuring index access through Splunk Web. If the user’s role already allows access to the remote index name through another method, such as a matching regular expression in the srchIndexesAllowed setting in the authorize.conf file or a role update made through the Splunk platform REST API, you do not need to create a placeholder index on the federated search head.