SmartStore on Azure Blob security strategies
SmartStore security strategies vary according to the type of remote storage service. Read this topic to understand how to configure encryption 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:
|
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.
Encrypt 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
Encrypt 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
Encrypt with azure-sse-c
You can configure server-side encryption with customer-provided keys (SSE-C) for Azure Blob Storage as follows:
remote.azure.encryption = azure-sse-c
Specify encryption scheme as azure-sse-c to map to Azure customer-provided encryption keys encrypted using an AzureKey Vault key. See the Azure documentation for customer-provided keys for Azure Store encryption for details.
remote.azure.tenant_id = <string>
Specify the ID of the tenant (instance of an Azure AD directory). Check your Azure subscription for details. It is needed only for client token-based authentication.
remote.azure.client_id = <string>
Specify the ID of the client, also called application ID, the unique identifier Azure AD issues to an application registration that identifies a specific application and the associated configurations. You can obtain the client ID for an application from the Azure Portal in the Overview section for the registered application. It is needed only for client token-based authentication and optional for managed identity authentication.
remote.azure.encryption.azure-sse-c.key_type = azure_kv
Determines the mechanism that the Splunk indexer uses to generate the key for sending data to Azure Storage. Specify "azure_kv", indicating Azure Key Vault Key Management Service (Azure KMS). You must also specify the required KMS settings: 'remote.azure.azure_kv.key_name', 'remote.azure.azure_kv.key_vault_tenant_id', 'remote.azure.azure_kv.key_vault_client_id' and 'remote.azure.azure_kv.key_vault_client_secret'. If you do not specify those settings, the indexer cannot start while 'remote.azure.encryption' has a value of "azure-sse-c".
Following is an example of setting server-side encryption with customer-provided encryption keys:
[volume:splunkcloud_vol] storageType = remote path = azure://xeric-xantus-z26 remote.azure.endpoint = https://xericxantusz26s.blob.core.windows.net/ remote.azure.container_name = s2-bucket remote.azure.sslVerifyServerCert = false remote.azure.sslVerifyServerName = false remote.azure.encryption = azure-sse-c remote.azure.tenant_id = 5ee5d344-e476-4d37-94d9-fd113e8b0a66 remote.azure.client_id = 46a98d28-02c3-45f3-bdbe-9ff3fffff170 remote.azure.encryption.azure-sse-c.key_type = azure_kv remote.azure.azure_kv.endpoint = https://xeric-xantus-z26-kv.vault.azure.net remote.azure.azure_kv.key_name = xeric-xantus-z26-stack-disk-key
SmartStore on GCS security strategies | Deploy SmartStore on a new indexer cluster |
This documentation applies to the following versions of Splunk® Enterprise: 9.4.1
Feedback submitted, thanks!