CARVIEW |
Securing Splunk Enterprise
- Install Splunk Enterprise securely
- Secure your admin account
- About TLS encryption and cipher suites
- Securing Splunk Enterprise with FIPS
- About default certificate authentication
- Secure Splunk Enterprise on your network
- Disable unnecessary Splunk Enterprise components
- Secure Splunk Enterprise service accounts
- Deploy secure passwords across multiple servers
- Harden the network port that App Key Value Store uses
- Some best practices for your servers and operating system
- Use access control to secure Splunk data
- About user authentication
- About configuring role-based user access
- About defining roles with capabilities
- Add and edit roles with Splunk Web
- Add and edit roles with authorize.conf
- Configure access to manager consoles and apps in Splunk Enterprise
- Find existing users and roles
- Delete all user accounts
- Secure access for Splunk knowledge objects
- Use network access control lists to protect your deployment
- Set up user authentication with LDAP
- Manage Splunk user roles with LDAP
- LDAP prerequisites and considerations
- Secure LDAP authentication with transport layer security (TLS) certificates
- How the Splunk platform works with multiple LDAP servers for authentication
- Configure LDAP with Splunk Web
- Map LDAP groups to Splunk roles in Splunk Web
- Configure LDAP with the configuration file
- Map LDAP groups and users to Splunk roles using configuration files
- Test your LDAP configuration on Splunk Enterprise
- Change authentication schemes from native to LDAP on Splunk Enterprise
- Remove an LDAP user safely on Splunk Enterprise
- Configure single sign-on with SAML
- Configure SSO with PingIdentity as your SAML identity provider
- Configure SSO with Okta as your identity provider
- Configure SSO with Microsoft Azure AD or AD FS as your Identity Provider
- Configure SSO with OneLogin as your identity provider
- Configure SSO with Optimal as your identity provider
- Configure SSO in Computer Associates (CA) SiteMinder
- Secure SSO with TLS certificates
- Configuring SAML in a search head cluster
- Configure Ping Identity with leaf or intermediate SSL certificate chains
- Configure SAML SSO for other IdPs
- Configure advanced settings for SSO
- Map groups on a SAML identity provider to Splunk roles
- Modify or remove role mappings
- Configure SAML SSO in the configuration files
- Troubleshoot SAML SSO
- Download Splunk Conf 2016 Session materials
- Bare Bones Splunk
- Stuck with Splunk ES Upgrade
- Can I get an overview of how Splunk permissions wo...
- What add-ons are needed for the Blue Coat apps, an...
- javaagent do not show any business transaction
- Problem in installing appdynamic agent on Adobe CQ...
- no load detected for this time range : standard ja...
- What's new in Splunk Enterprise 6.3.1?
- How do I install and configure the Splunk for Iron...
Configure access to manager consoles and apps in Splunk Enterprise
On Splunk Enterprise instances only, you can use the local.meta file to grant and restrict access to certain parts of your Splunk Enterprise instance.
This file is not accessible on Splunk Cloud instances. On a Splunk Cloud instance, use and edit roles with Splunk Web to grant access to your Splunk Cloud deployment.
Examples of managing access to manager consoles and Splunk apps
With the local.meta file, you can:
- Restrict users in custom roles to a specific app
- Let users who hold custom roles access administrator-level features
Grant admin roles to users
Some management abilities that belong to the admin role are unique to that role. These abilities do not automatically inherit from the admin role when you configure the role in Splunk Web or by using the authorize.conf
configuration file.
For example, say you want to create a custom role that inherits all of the abilities of the admin role but that has limited access to search jobs. To do this, you would create a new role called "specialAdmin" and set it to inherit all of the capabilities of the admin role, as described in About defining roles on the Splunk platform with capabilities. Then, you would set your search limits, as described in About configuring role-based user access.
Restrict access to specific apps
You can also use the local.meta
file to restrict access.
For example, say you want to allow a user access to only one dashboard view. To accomplish this, you could create an app for that view and assign the user role to that app. In this case, you can use the local.meta file to let the role view that app.
Add and remove access using the local.meta file
You can give or restrict access by editing the local.meta file to add the new role wherever you want it. This action is not possible on Splunk Cloud Platform instances, it is available only on Splunk Enterprise.
- Locate the
local.meta
file. Its location depends on several factors.- If you want to edit access for the main search page, for example, the manager controls, look in
$SPLUNK_HOME/etc/system/metadata/
. - If you want to edit access to a particular app, look in
$SPLUNK_HOME/etc/apps/<app_name>/metadata/
. - If the directory for the desired location does not contain the file, you can copy the default version
default.meta
and rename the copied file to local.meta.Do not edit the
default.meta
file directly as you might need the default values in that file at a future time.
- If you want to edit access for the main search page, for example, the manager controls, look in
- Open the local.meta file for editing.
- In the
local.meta
file, add the name of the new role to the stanza that corresponds with the access you want. See the table at the end of this procedure for details. - Save the file and close it.
- Restart Splunk Enterprise.
Default stanza | What it does |
---|---|
[manager/accesscontrols]
|
Lets users read this app's contents, or access functions in the Splunk Web Manager page, depending on the directory you are in. Unless overridden by other metadata, lets only admin and power users share objects into this app. |
|
Determines the access controls for the Manager page access. |
Examples for using local.meta to grant and remove access to Splunk Enterprise components
Following are some examples of editing the local.meta file to customize access to parts of Splunk Enterprise.
Example 1: Configure a role that allows for user management but no data access
You set up a new role called "usermanager" that only inherits capabilities from the user role and does not inherit any searches or indexes. You want this role to be able to create and manage user accounts, but have no data access.
To configure this access, edit the following stanza of the local.meta file:
[manager/accesscontrols] access = read : [ admin ], write : [ admin ]
To include the following:
[manager/accesscontrols] access = read : [ admin, usermanager ], write : [ admin, usermanager ]
This lets the "usermanager" role that you created see and edit things in the "Access controls" pages in Splunk Enterprise Manager.
Example 2: Configure a role that lets users view, but not edit, pages in Manager
You set up a new role called "userview," that you want to access, but not edit, pages in Manager. In this case, only add the role to the "read" value:
[manager/accesscontrols] access = read : [ admin, userview, usermanager ], write : [ admin, usermanager ]
You can also grant access to read the manager pages to any using the asterisk *
, which acts as a wildcard:
[manager/accesscontrols] access = read : [ * ], write : [ admin ]
Example 3: Configure a role that limits write access to an app or dashboard
You want a subset of users who can only read sales data that you specify. To accomplish this, you can create an app for the dashboard and then create a new role "salesusers."
In the local.meta
file in your app directory, edit the following stanza:
[viewstates] access = read : [ * ], write : [ * ] to read: [viewstates] access = read : [ salesusers ], write : [ admin ]
Add and edit roles with authorize.conf | Find existing users and roles |
This documentation applies to the following versions of Splunk® Enterprise: 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, 7.3.9, 8.0.0, 8.0.1, 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.1.14, 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, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.1.7, 9.1.8, 9.1.9, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.2.5, 9.2.6, 9.3.0, 9.3.1, 9.3.2, 9.3.3, 9.3.4, 9.4.0, 9.4.1, 9.4.2
Comments
Configure access to manager consoles and apps in Splunk Enterprise
You must be logged into splunk.com in order to post comments. Log in now.
Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.
Your Comment Has Been Posted Above
Feedback submitted, thanks!