Splunk® Enterprise

Managing Indexers and Clusters of Indexers

Splunk Enterprise version 8.1 will no longer be supported as of April 19, 2023. See the Splunk Software Support Policy for details. For information about upgrading to a supported version, see How to upgrade Splunk Enterprise.
This documentation does not apply to the most recent version of Splunk® Enterprise. For documentation on the most recent version, go to the latest release.

SmartStore on GCS security strategies

SmartStore security strategies vary according to the type of remote storage service. This topic covers security when using Google Cloud Storage (GCS) as the remote storage service.

Authenticate with the remote storage service

The indexer uses a credential file to authenticate with GCP.

How the indexer obtains its credential

The indexer can obtain its credential in several ways. In descending order of precedence, the indexer uses:

  1. The credential file specified by the remote.gs.credential_file setting in indexes.conf, if set.
  2. The credential for the account associated with the remote.gs.service_account_email setting in indexes.conf, if set,
  3. The credential for the Compute Engine's default service account.

Specify a custom credential on the indexer

To specify a custom credential on the indexer, use the remote.gs.credential_file setting in indexes.conf:

remote.gs.credential_file = <credentials.json>

The file specified by this setting must located on the indexer as follows:

  • For standalone indexers, the file must be located under $SPLUNK_HOME/etc/auth.
  • For peer nodes in a cluster, you can distribute the file through the configuration bundle method, putting the file under the $SPLUNK_HOME/etc/master-apps/_cluster/local directory on the manager node and distributing the bundle to each of the peer nodes, causing the file to reside under their $SPLUNK_HOME/etc/slave-apps/_cluster/local directories. You can also put the file in $SPLUNK_HOME/etc/auth on each peer node. The distributed bundle location has precedence.

The credential file is encrypted on startup.

Credential permissions

The credentials that you use need permission to perform GCS operations. They also need permission to perform GCP Key Management Service (KMS) operations if you are using the gcp-sse-c or gcp-sse-kms encryption schemes.


Manage SSL certifications for the remote store

The SSL certification settings vary according to the remote storage service type. This section provides information for managing SSL for a GCS remote store, using the settings provided in indexes.conf. For more details on any of these settings, as well as for information on additional GCS-related SSL settings, see the indexes.conf spec file.

The GCS SSL settings are overlaid on the sslConfig stanza in server.conf for caCertFile (sslRootCAPath) and cipherSuite.Therefore, if you run into issues, consult the server.conf SSL settings, in addition to the remote-storage-specific settings.

Specify SSL settings on a per-remote-volume basis.

The following table includes common attributes and their recommended values.

SSL setting Description Recommended value
remote.gs.sslVerifyServerCert Specifies whether to check the server certificate provided by the GCS endpoint. true
remote.gs.sslVerifyServerName Specifies whether to verify that either the Common Name or Subject Alternate Name in the server certificate matches the hostname in the URL it connects to. true
remote.gs.sslVersionsForClient Specifies the minimum SSL/TLS version to use for outgoing connections. tls1.2
remote.gs.sslRootCAPath Absolute path to the PEM format file containing list of root certificates. N/A
remote.gs.cipherSuite Ciphers to use to connect with GCS. Check with your security experts. Here is an example of the type of value to enter for this attribute:


ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256

Encrypt the data on the remote store

SmartStore supports server-side encryption of data-at-rest on GCS. SmartStore supports three encryption schemes through the remote.gs.encryption attribute in indexes.conf:

remote.gs.encryption = gcp-sse-c | gcp-sse-kms | gcp-sse-gcp

The default is "gcp-sse-gcp".

Configure this attribute on a per-volume basis.

The recommended method for encryption on the remote store is "gcp-sse-c" (server-side encryption with customer keys). This method avoids running into potential throttling issues from KMS.

Choosing the encryption method is a one-time decision. You cannot change the encryption method later.

For details on encryption modes, see:

  • The indexes.conf spec file for the remote.gs encyrption-related settings.
  • The Google documentation on configuring Cloud Storage encryption keys.

Encryption with gcp-sse-c

Here is an example of setting server-side encryption with customer-supplied encryption keys:

[volume:my_gcs_vol]
storageType = remote
path = gs://your_gcp_test_1
remote.gs.project_id = your-app-test
remote.gs.encryption = gcp-sse-c
remote.gs.encryption.gcp-sse-c.key_refresh_interval = 86400
remote.gs.encryption.gcp-sse-c.key_type = gcp_kms
remote.gs.gcp_kms.locations = us-central1
remote.gs.gcp_kms.key_ring = your_ring_1
remote.gs.gcp_kms.key = test_key_1

Encryption with gcp-sse-gcp

Here is an example of setting server-side encryption with Google-managed encryption keys:

[volume:my_gcs_vol_3]
storageType = remote
remote.gs.encryption = gcp-sse-gcp
path = gs://your_gcp_test_3

Encryption with gcp-sse-kms

When configuring the GCS bucket, you can either specify the key or, by default, use the key associated with the GCS bucket.

Here is an example of setting server-side encryption with customer-managed encryption keys:

[volume:my_gcs_vol_2]
storageType = remote
path = gs://your_gcp_test_2
remote.gs.project_id = your-app-test
remote.gs.encryption = gcp-sse-kms
remote.gs.gcp_kms.locations = us-central1
remote.gs.gcp_kms.key_ring = your_ring_us
remote.gs.gcp_kms.key = test_key_3

If you want to use the key associated with the GCS bucket service account, leave the key settings empty:

[volume:my_gcs_vol_2]
storageType = remote
path = gs://your_gcp_test_2
remote.gs.project_id = your-app-test
remote.gs.encryption = gcp-sse-kms
Last modified on 05 January, 2022
SmartStore on S3 security strategies   Deploy SmartStore on a new indexer cluster

This documentation applies to the following versions of Splunk® Enterprise: 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


Was this topic useful?







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.

0 out of 1000 Characters