Related Answers
Download topic as PDF
Set a security key for the search head cluster
The security key authenticates communication between all cluster members, as well as between members and the deployer instance.
For an overview of search head clustering configuration, see "Configure the search head cluster".
Security key must be identical across all nodes
You must set the key to the same value on all search head cluster members and the deployer.
Set the security key during deployment
It is recommended that you set the security key during initial cluster deployment. See "Deploy a search head cluster".
Set the security key post-deployment
If you neglected to set the key during deployment, you can set it post-deployment by configuring the pass4SymmKey attribute in server.conf on each cluster member and the deployer. Put the attribute under the [shclustering] stanza. For example:
[shclustering] pass4SymmKey = yoursecuritykey
You must restart each instance for the key to take effect. For more information on post-deployment configuration, see "Configuration methods."
Keep a copy of the security key
You should save a copy of the key in a safe place. Once an instance starts running, the security key changes from clear text to encrypted form, and it is no longer recoverable from server.conf. If you later want to add a new member, you will need to use the clear text version to set the key.
Multiple search head clusters and the security key
If your deployment includes multiple search head clusters, it is a best practice to use a different key for each cluster. By doing so, you avoid any possibility of mismatching clusters and their deployers, which could result in the content for one cluster being wrongly downloaded to a different one.
Set the security key for a combined search head cluster and indexer cluster
For information on setting the security key for a combined search head cluster and indexer cluster, see Integrate the search head cluster with an indexer cluster in Distributed Search.
|
PREVIOUS Choose the replication factor for the search head cluster |
NEXT How configuration changes propagate across the search head cluster |
This documentation applies to the following versions of Splunk® Enterprise: 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 6.2.9, 6.2.10, 6.2.11, 6.2.12, 6.2.13, 6.2.14, 6.2.15, 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 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.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.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.3.0, 7.3.1, 7.3.2, 7.3.3, 8.0.0
Comments
The page at : http://docs.splunk.com/Documentation/Splunk/7.1.1/DistSearch/SHCandindexercluster
directly contradict the one I'm commenting on.
On the linked page, read the comments from the Splunk staffer and the "Note" block on the page that document the difference between the indexer cluster secret key and the shcluster secret key.
It says they are different, are setup under different stanzas and that it is recommended that they be different for both "types" of clusters.
The current pages contradict this by saying:
"If the search head cluster is part of an indexer cluster, the same key must be used across both cluster types."
And further says:
"Put the attribute under the [shclustering] or [general] stanza."
"If the search head cluster is part of an indexer cluster, set the key in the [general] stanza, so that the instance uses the same key in its two roles of both a search head cluster member and an indexer cluster node."
One has to be right and the other wrong and confusing.
Martinr ubi -
Thank you for noting the discrepancy between the two pages. The discussion on the page you cited ( http://docs.splunk.com/Documentation/Splunk/7.1.1/DistSearch/SHCandindexercluster ) is the correct one.
I have updated the mention of combined clusters on this page to refer to that one.