Splunk® Enterprise

Managing Indexers and Clusters of Indexers

Splunk Enterprise version 9.0 will no longer be supported as of June 14, 2024. See the Splunk Software Support Policy for details. For information about upgrading to a supported version, see How to upgrade Splunk Enterprise.

SmartStore on Azure Blob security strategies

SmartStore security strategies vary according to the type of remote storage service. This topic covers security when using Azure Blob storage as the remote storage service.

Authenticate with the remote storage service

The best practice is to authenticate through Azure Active Directory using managed identities. Authorizing access with Azure Active Directory provides superior security and ease of use over other authorization options.

SmartStore on Azure Blob supports the following managed-identity-based authentication methods:

  • Authentication through system-assigned managed identity assigned to the Azure Virtual Machine that the indexer instance is running on.
  • Authentication through user-assigned managed identity using the registered application's client secret.

The client secret method is configured in each indexer's indexes.conf file:

  • remote.azure.tenant_id: The ID of the tenant. The tenant is an instance of an Azure AD directory. Check your Azure subscription for details.
  • remote.azure.client_id: The ID of the client. This ID is also known as the application ID, the unique identifier that Azure AD issues to an application registration. The ID identifies a specific application and its associated configurations. You can obtain the client ID for an application from the Azure Portal in the Overview section for the registered application.
  • remote.azure.client_secret: The secret key to use when authenticating through the client secret method. You generate the secret key through the Azure Portal.

For more information on these settings, see the indexes.conf spec file.

Appropriate access policies and permissions need to be assigned to the security principal to allow access to the Azure container.

Caution: You can also use access/secret keys authentication. This method has security implications, but it might be appropriate for smaller or test deployments, depending on your needs. For more information on this method, see the entries for remote.azure.access_key, remote.azure.secret_key, and remote.azure.endpoint in the indexes.conf spec file.

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 an Azure Blob remote store, using the settings provided in indexes.conf. For more details on any of these settings, as well as for information on additional Azure-related SSL settings, see the indexes.conf spec file.

The Azure 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.azure.sslVerifyServerCert Specifies whether to check the server certificate provided by the Azure endpoint. true
remote.azure.sslVerifyServerName Specifies whether to verify that either the Common Name or Subject Alternative Name in the server certificate matches the hostname in the URL it connects to. true
remote.azure.sslVersions Specifies the minimum SSL/TLS version to use for outgoing connections. tls1.2
remote.azure.sslRootCAPath Absolute path to the PEM format file containing list of root certificates. N/A
remote.azure.cipherSuite Ciphers to use to connect with Azure Blob storage. 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 Azure Blob storage. SmartStore supports two encryption schemes through the remote.azure.encryption attribute in indexes.conf:

remote.azure.encryption = azure-sse-kv | azure-sse-ms 

Configure this attribute on a per-volume basis.

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

These encryption schemes let you choose between Microsoft-managed keys or customer-managed keys fully configured on the Azure Blob storage account side (transparent from Splunk Enterprise point-of-view)

The default is "azure-sse-ms". (Microsoft-managed keys).

For details on encryption modes, see:

  • The indexes.conf spec file for the remote.azure encyrption-related settings.
  • The Azure documentation on configuring Azure Blob storage encryption keys.

Encryption with azure-sse-ms

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

[volume:azure_storage_ms_keys]
storageType = remote
path = azure://my/msencrypted/storage
remote.azure.encryption = azure-sse-ms

Encryption with azure-sse-kv

Customer-managed keys require an encryption scope. To create an encryption scope, use either keys kept in a key vault or the Microsoft-managed keys.

Encryption scope must be already configured in the storage account before you can enable azure-sse-kv.

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

[volume:azure_storage_kv_keys]
storageType = remote
path = azure://my/cmencrypted/storage
remote.azure.encryption = azure-sse-kv
remote.azure.azure-sse-kv.encryptionScope = customer_key_scope_1
Last modified on 29 June, 2023
SmartStore on GCS security strategies   Deploy SmartStore on a new indexer cluster

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.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.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.3.0, 9.3.1, 9.3.2


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