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:
The credential file specified by the
indexes.conf, if set.
The credential for the account associated with the
indexes.conf, if set,
- 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
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
- For peer nodes in a cluster, you can distribute the file through the configuration bundle method, putting the file under the
$SPLUNK_HOME/etc/manager-apps/_cluster/localdirectory on the manager node and distributing the bundle to each of the peer nodes, causing the file to reside under their
$SPLUNK_HOME/etc/peer-apps/_cluster/localdirectories. See "Structure of the configuration bundle" for information on the
manager-appsdirectory. You can also put the file in
$SPLUNK_HOME/etc/authon each peer node. The distributed bundle location has precedence.
The credential file is encrypted on startup.
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
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|
||Specifies whether to check the server certificate provided by the GCS endpoint.||true|
||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|
||Specifies the minimum SSL/TLS version to use for outgoing connections.||tls1.2|
||Absolute path to the PEM format file containing list of root certificates.||N/A|
||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:
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
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
- 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
SmartStore on S3 security strategies
SmartStore on Azure Blob security strategies
This documentation applies to the following versions of Splunk® Enterprise: 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.1.0, 9.1.1, 9.1.2