Splunk® Enterprise

Securing Splunk Enterprise

Introduction to securing the Splunk platform with TLS

For the highest level of security in your Splunk platform deployment, you must secure communications between Splunk platform instances that you manage with Transport Layer Security (TLS) technology.

While Splunk manages certificates on Splunk Cloud Platform, and provides certificates for forwarders to connect to SCP to send data, it isn't possible for Splunk to protect an external deployment.

Whether the external deployment is a Splunk Enterprise instance or cluster, or is a tier of forwarders that sends data to Splunk Cloud Platform, you are responsible for securing connectivity between those Splunk components.

Read this topic to learn what TLS is, how TLS certificates work, and how to set up and configure certificates in the Splunk platform instances that you manage directly.

About transport layer security and how the Splunk platform uses it

TLS is a communications protocol that lets two computers, applications, or computing processes communicate securely and privately over a network. It provides for confidentiality and authentication and data integrity protections for that communication.

Splunk uses TLS to ensure that communications between Splunk platform instances, including Splunk Web, are protected from potential malicious actors. Splunk uses TLS extensively with every Splunk Cloud Platform instance. TLS is also an important part of Splunk platform deployments that you manage.

A large part of how TLS works is the digital certificate. Digital certificates are files that let entities that communicate using TLS to safely establish connections and encrypt data between one another. They let these entities prove to each other that they are who they say they are. Each instance in a Splunk platform deployment has at least one certificate, but can have many depending on the functions that the instance performs.

A certificate authority (CA) issues and signs the certificates, which adds a layer of authenticity to the certificates by proving the identity of the certificate owner. Typically, a CA signs a certificate for a specific domain name or group of domain names.

For increased security, all certificates have a finite time in which they are valid. When the validity of the certificate expires, you must replace it with a new certificate. Typically, certificates last anywhere from 90 days to 1 year, but can be shorter or longer.

When a certificate is valid, communications between the two entities that use the certificate is secure. Invalid certificates prevent entities from communicating with one another securely, and can let outside parties read sensitive data as the entities transmit it.

Why it is important to secure your Splunk Enterprise deployment with TLS certificates

It's important to secure your Splunk Enterprise and forwarding tier infrastructure for the following reasons:

  • It's a Splunk best practice. Splunk includes certificates with every installation, and while they are not proprietary to your specific application, they provide a basic level of protection from outside parties. You can increase that level of protection by obtaining and installing your own certificates.
  • Firewalls, if you use them, only provide protection from outside actors. If a malicious actor gets inside your network through your firewall, they can easily access machines inside the network, especially if you use the default certificates in your Splunk Enterprise deployment.
  • It protects your data. When you secure your Splunk Enterprise infrastructure with certificates, and particularly when you use certificates that a verified third party certificate authority provides, your data is the most secure that it can be, and malicious actors that want access to it have a very hard time getting it.

About the default Splunk platform certificates

The Splunk platform installation package comes with a set of default certificates. Splunk Inc. acts as the certificate authority for the certificates because it created the software that is in the installation package. When you install Splunk Enterprise or the universal forwarder, the installer signs and places these certificates in the installation directory to let the installation communicate with other Splunk platform instances securely.

These certificates discourage casual snoopers, and are technically secure. The problem is, because the root certificate is the same in every Splunk installer, anyone with the same root certificate can authenticate into and communicate with the instance if they are on the same network. The root certificate can't be different from installer to installer, because each installer would have to be different.

The default certificates exist in every Splunk Enterprise installation. There is a certificate for handling connections between Splunk platform instances, also known as inter-Splunk or Splunk-to-Splunk communications, and an additional certificate for communications between your browser and Splunk Web and Splunk Web and other Splunk platform instances, such as search heads.

Methods to secure the Splunk platform

Splunk Cloud Platform configures TLS encryption for inter-Splunk communications and Splunk Web for nearly all instance types that Splunk manages. Splunk Cloud Platform always receives updates to security protocols, best practices, and configurations, and if you use Splunk Cloud Platform, in nearly all cases, you don't have to worry about the administrative work that is necessary to maintain certificates there.

You are responsible for the security of Splunk infrastructure that you manage, even infrastructure that connects to a Splunk Cloud Platform instance. A Splunk best practice is to use certificates that you obtain yourself to perform securement of your infrastructure. You can apply encryption or authentication using your own certificates for:

  • Communications between the browser you use and Splunk Web
  • Communication between other Splunk instance types, such as between forwarders and indexers, or between Splunk processes that use the Splunk management network port

Table of most common encrypted Splunk platform instance communication scenarios

The following table describes the most common communication scenarios and the default TLS settings. To understand the contents of the table, see the following column descriptions:

  • Type of exchange: What kind of communication occurs between the two nodes
  • Node A function: The entity that initiates the connection to the other entity; also known as the client
  • Node B function: The entity that responds to the client request; also known as the server
  • Default encryption: Whether or not there is encrypted communication between the two entities
  • Default certificate-based authentication: Whether or not the entities use certificates for encrypted communications by default.
  • Default Common Name checking: Whether or not the entities look at the certificates they receive and verify that the Common Name field within the certificate matches a certain host name or range of host names. The Common Name field typically contains the fully-qualified host name of the computer that the certificate was generated to protect
  • Type of data exchanged: The kind of data that the entities exchange after they establish communications
  • Cloud refers specifically to Splunk Cloud Platform. Enterprise in this table refers specifically to Splunk Enterprise and its components or the universal forwarder.


Type of exchange Node A function Node B function Default encryption Default certificate-based authentication Default Common Name checking Type of data exchanged
Browser to Splunk Web Browser Splunk Web Cloud: enabled
Enterprise: disabled
Browser determines this Browser determines this configuration and search data
Splunk Web to search head Splunk Web splunkd as a search head enabled Cloud: enabled
Enterprise: disabled
Cloud: enabled
Enterprise: disabled
configuration and search data
Forwarding splunkd as a forwarder splunkd as an indexer Cloud: enabled
Enterprise: disabled
Cloud: enabled
Enterprise: disabled
Cloud: enabled
Enterprise: disabled
data to be indexed
Splunk-to-Splunk splunkd as a client splunkd as a server enabled disabled disabled configuration data, user data
Deployment server to deployment clients splunkd as a deployment client splunkd as deployment server enabled Cloud: enabled
Enterprise: disabled
Cloud: enabled
Enterprise: disabled
configuration data
Distributed search splunkd as search peer splunkd as a search head enabled Cloud: enabled
Enterprise: disabled
Cloud: enabled
Enterprise: disabled
search data
Search head clusters splunkd as cluster members splunkd as cluster members Cloud: enabled
Enterprise: disabled
Cloud: enabled
Enterprise: disabled
Cloud: enabled
Enterprise: disabled
cluster data
Search head cluster deployer splunkd as cluster members splunkd as cluster deployer enabled Cloud: enabled
Enterprise: disabled
Cloud: enabled
Enterprise: disabled
configuration data
Indexer cluster peer nodes splunkd as indexer cluster peer nodes splunkd as indexer cluster peer nodes Cloud: enabled
Enterprise: disabled. You must use the replication_port-ssl setting in the server.conf configuration file to enable replication of data over TLS
'Cloud: enabled
Enterprise: disabled
Cloud: enabled
Enterprise: disabled
replication data
Indexer cluster manager (or master) splunkd as peer and search head nodes splunkd as a manager (or master) node enabled Cloud: enabled
Enterprise: disabled
Cloud: enabled
Enterprise: disabled
cluster data

For the most secure types of communications, best practice is to use your own certificates. You can either obtain them from a third party or generate them yourself.

Next steps

Now that you understand the basics of TLS and how it can secure your Splunk Enterprise deployment, see the following decision tree for next steps.

If you use a Splunk Cloud Platform instance, do not manage Splunk Enterprise infrastructure, and need only to connect Splunk universal or heavy forwarders to your Splunk Cloud Platform instance, see the following topic to connect your forwarders to Splunk Cloud Platform:

If you know how TLS works, have already obtained certificates, and just need to know how to configure them to use with the Splunk platform, see the following topic:

Otherwise, continue for an overview of how to secure your deployment with TLS and the procedures to obtain TLS certificates:

Last modified on 11 July, 2024
Use the getSearchFilter function to filter at search time   Steps for securing your Splunk Enterprise deployment with TLS

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


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