Install Splunk Enterprise Security in a search head cluster environment
Splunk Enterprise Security has specific requirements and processes for implementing search head clustering.
- For an overview of search head clustering, see Search head clustering architecture in the Distributed Search Manual.
- For a complete list of search head clustering requirements, see System requirements and other deployment considerations for search head clusters in the Distributed Search Manual.
If you are installing Enterprise Security on an existing search head cluster environment which might have other apps deployed already, all of the steps in this section apply. Be careful to not delete or remove any existing content in the
Prerequisites for installing Enterprise Security in a search head cluster environment
Splunk Enterprise Security supports installation on Linux-based search head clusters only. At this time, Windows search head clusters are not supported by Splunk Enterprise Security.
Before installing Enterprise Security in a search head cluster environment, verify that you have:
- One deployer
- The same version of Splunk Enterprise on the deployer and search head cluster nodes
- The same app versions of any other apps on the deployer and search head cluster nodes (not yet including Enterprise Security)
- The backup of
etc/shcluster/appson the deployer before installing Enterprise Security
- The backup of
etc/appsfrom one of search head cluster nodes
- The backup of the KVstore from one of search head cluster nodes
- Verify that your
server.conf shclusteringconfiguration is in
$SPLUNK_HOME/etc/system/local/server.confor is in an app that exports the server configuration globally via metadata:[server]
export = system
Installing Enterprise Security in a search head cluster environment
The installer dynamically detects if you're installing in a single search head environment or search head cluster environment. To install Enterprise Security on a search head cluster:
- Prepare the deployer per the prerequisites.
- Install Enterprise Security on the deployer.
- On the Splunk toolbar, select Apps > Manage Apps and click Install App from File.
- Click Choose File and select the Splunk Enterprise Security product file.
- Click Upload to begin the installation.
- Click Continue to app setup page
Note the message that Enterprise Security is being installed on the deployer of a search head cluster environment and that technology add-ons will not be installed as part of the post-install configuration.
- Click Start Configuration Process.
- Wait for the process to complete.
- Use the deployer to deploy Enterprise Security to the cluster members. From the deployer, run this command:
splunk apply shcluster-bundle
To verify that Enterprise Security is deployed to the cluster members:
- From the GUI of a cluster member, you can check the Help > About menu to check the version number.
- From the CLI of a cluster member, you can check the
/etc/appsdirectory to verify the supporting add-ons and domain add-ons for Enterprise Security:
DA-ESS-AccessProtection, DA-ESS-EndpointProtection, DA-ESS-IdentityManagement, DA-ESS-NetworkProtection, DA-ESS-ThreatIntelligence, SA-AccessProtection, SA-AuditAndDataProtection, SA-EndpointProtection, SA-IdentityManagement, SA-NetworkProtection, SA-ThreatIntelligence, SA-UEBA, SA-Utils, Splunk_DA-ESS_PCICompliance, SplunkEnterpriseSecuritySuite, Splunk_SA_CIM, Splunk_SA_ExtremeSearch
- From the CLI of a cluster member, you can check the
$SPLUNK_HOME/etc/apps/SplunkEnterpriseSecuritySuite/local/inputs.conffile to see that the data model accelerations settings are enabled.
Although technology add-ons are bundled in the installer, they are not deployed as part of the installation process. You must deploy them manually if you want to use them. See Deploy add-ons included with Splunk Enterprise Security.
Managing configuration changes in a search head cluster
Some system configuration changes must be deployed using the deployer.
- Instead of making the changes on a search head cluster member, make the changes on a deployer.
- Migrate the necessary files to the search head cluster deployer.
- Deploy the updated configuration to the search head cluster.
Configuration changes that must be deployed using the deployer:
|Configuration change||File modified|
|Enable or disable indexed real-time searches on the General Settings page.|
|Modify the indexed real-time disk sync delay on the General Settings page.|
|Send notable events to Splunk UBA on the UBA Setup page.|
Most configuration changes that you make in a search head cluster replicate automatically to other search head cluster members. For example:
- Add, modify, and disable threat intelligence sources
- Add, modify, and disable asset and identity source lists
- Changes to the user interface
- Changes to searches
See How configuration changes propagate across the search head cluster in the Distributed Search Manual.
Migrate an existing search head to a search head cluster
An Enterprise Security standalone search head or search head pool member cannot be added to a search head cluster. To migrate ES configurations to a search head cluster:
- Identify any custom configurations and modifications in the prior ES installation. Check to make sure there is no local copy of
ess_setup.confthat could conflict with the default one when you deploy Enterprise Security to the cluster.
- Implement a new search head cluster.
- Deploy the latest version of Enterprise Security on the search head cluster.
- Review and migrate the customized configurations to the search head cluster deployer for replication to the cluster members.
- Shut down the old ES search head.
For more information, see the topic Migrate from a standalone search head to a search head cluster in the Splunk Enterprise Distributed Search Manual.
For assistance in planning a Splunk Enterprise Security deployment migration, contact Splunk Professional Services.
Back up and restore Splunk Enterprise Security in a search head cluster environment
Back up and restore a Splunk Enterprise Security search head cluster (SHC) environment with at least three SHC nodes. All of the nodes in the SHC must be running the same version of Splunk Enterprise Security. Restoring an SHC environment might be necessary in the event of a disaster.
Take regular backups from the SHC, so that you have a backup from a time when the environment is healthy. For example, you could automate taking backups every hour. Choose a frequency of backups based on recovery point objectives.
To check if your environment is healthy, you can use one of the following methods:
- CLI command:
./splunk show shcluster-status –verbose
In the output, look for the following fields:
|dynamic_captain||Whether the cluster has a dynamically elected captain.|
|stable_captain||Whether the cluster captain is in a stable state.|
|service_ready_flag||Whether the cluster has enough members to support replication factor.|
|splunk_version||Whether all members, including the cluster master, are running Splunk version 7.1.0.|
|out_of_sync||Whether all nodes are currently in-sync.|
Back up a search head cluster environment
Back up an SHC environment by backing up the KV store, the deployer, and the SHC nodes. The backup procedure does not require shutting down the SHC cluster or any node in the cluster.
Back up the KV store
To back up the KV store, run the following command from the CLI from the SHC node with the most recent data:
splunk backup kvstore -auth "admin:<password>"
This command creates an archive file in the
$SPLUNK_HOME/var/lib/splunk/kvstorebackup directory. For example, the file might be named
Back up the deployer and search head cluster nodes
- On the deployer, back up the files in the
- On the SHC node with the most recent data, note the GUID from the
shclusteringstanza from the
$SPLUNK_HOME/etc/system/local/server.conffile. This information is necessary during the restore process.
- On the SHC node with the most recent data, back up the files in the
- Create a
tar.gzfile from these backups.
Restore from a backup of a search head cluster environment
You need the following information to restore from a backup:
- The GUID from the
server.conffile from one of the SHC members from before you begin restoring.
After your restore the cluster, the restored cluster will have the same GUID as the cluster that was backed up.
- A backup of the deployer.
- A backup of the SHC node with the most recent data.
- A backup of the KV store from the SHC node with the most recent data.
The restore procedure requires the SHC to be shut down, but not the KV store.
Restore the deployer
- On the deployer, extract the deployer backup file to the
- Apply the bundle with the following command:
splunk apply shcluster-bundle
Restore the search head cluster nodes
Complete the following steps on each SHC node that you want to restore:
- Run the following command to stop Splunk Enterprise Security:
- Create a temporary folder and name it
- Extract the SHC node backup file to the
- Move the
config.bundlefile from the
tempdirectory to the
- Extract the
config.bundlefile to the
Restore the KV store
- On an SHC node, check the
$SPLUNK_HOME/var/lib/splunk/kvstorebackupdirectory to make sure that the
kvdump_example.tar.gzbackup file that you want to use to restore is there. If it is not in that directory, manually copy your tar.gz file to that location. Note that the KV store backup file is not automatically replicated across each SHC member.
- Ensure that Splunk Enterprise Security is installed. The
collections.conffile is necessary to complete the restore.
- Run the following command to restore the KV store:
splunk restore kvstore -archiveName kvdump_example.tar.gz
- Restore the snapshot bundle by extracting the backup tar file from the
$SPLUNK_HOME/var/run/splunk/snapshotdirectory to the
- Repeat these steps on each SHC node that you want to restore. Restoring the KV store on one SHC node does not cause the KV store to automatically replicate across each SHC member.
Entries that are present in both the current KV store and in the backup are updated and replaced by the entry in the backup. Entries that are in the current KV store but not in the backup are not deleted or affected in any way.
Complete restoring the search head cluster environment
Finish restoring Splunk Enterprise Security from backup in an SHC environment.
- In the
$SPLUNK_HOME/etc/system/local/server.conffile, locate the
- Update the field ID in this stanza with the GUID copied from the
server.conffile during backup.
- Run the following command to restart Splunk:
Restore incident review history from internal audit logs
In the event that the backup process was not established prior to a data loss event with the KVStore, some of the information pertaining to incident review history can still be recovered using internal logs, as dictated by index _audit retention settings.
earliest=-30d index=_audit sourcetype=incident_review
| rex "@@\w+,(?<rule_name>[^,]+),(?<status>[^,]*),(?<owner>[^,]*),(?<urgency>[^,]*),(?<comment>.*),(?<user>[^,]+),
| eval time=_time
| table comment owner rule_id rule_name status time urgency user
| outputlookup append=t incident_review_lookup_REMOVE_FOR_SAFETY
Install Splunk Enterprise Security
Deploy add-ons included with Splunk Enterprise Security
This documentation applies to the following versions of Splunk® Enterprise Security: 5.3.0, 5.3.1