Splunk® Enterprise

Securing Splunk Enterprise

Acrobat logo Download manual as PDF


Acrobat logo Download topic as PDF

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. Read this topic to learn what TLS is, how TLS certificates work, and how to set up and configure them.

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 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 uses, your data is the most secure that it can be, and malicious actors that want access to it will 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 platform 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 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.

The security of Splunk infrastructure that you manage, even infrastructure that connects to a Splunk Cloud Platform instance, is your responsibility. A Splunk best practice is to use certificates that you obtain yourself to perform securement of your infrastructure. You can apply encryption and/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

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
  • Encryption: Whether or not there is encrypted communication between the two entities
  • Certificate-based Authentication: Whether or not the entities use certificates for encrypted communications by 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


Type of exchange Node A function Node B function Encryption Certificate Authentication Common Name checking Type of data exchanged
Browser to Splunk Web Browser Splunk Web NOT enabled by default Browser determines this Browser determines this configuration and search data
Splunk Web to search head Splunk Web splunkd as a search head enabled by default NOT enabled by default NOT enabled by default configuration and search data
Forwarding splunkd as a forwarder splunkd as an indexer NOT enabled by default NOT enabled by default NOT enabled by default data to be indexed
Deployment server to deployment clients splunkd as a deployment client splunkd as deployment server Enabled by default NOT enabled by default NOT enabled by default configuration data
Distributed search splunkd as search peer splunkd as a search head Enabled by default NOT enabled by default NOT enabled by default search data
Search head clusters splunkd as cluster members splunkd as cluster members NOT enabled by default NOT enabled by default NOT enabled by default cluster data
Search head cluster deployer splunkd as cluster members splunkd as cluster deployer Enabled by default NOT enabled by default NOT enabled by default configuration data
Indexer cluster peer nodes splunkd as indexer cluster peer nodes splunkd as indexer cluster peer nodes NOT enabled by default. You must use the replication_port-ssl setting in server.conf to enable replication of data over SSL NOT enabled by default NOT enabled by default replication data
Indexer cluster manager (or master) splunkd as peer and search head nodes splunkd as a manager (or master) node Enabled by default NOT enabled by default NOT enabled by default 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 step

Now that you understand the basics of TLS and how it can secure your Splunk Enterprise deployment, see the following link for an overview of how to secure your deployment with TLS.

Last modified on 13 June, 2022
PREVIOUS
Use the getSearchFilter function to filter at search time
  NEXT
Steps for securing your Splunk Enterprise deployment with TLS

This documentation applies to the following versions of Splunk® Enterprise: 9.0.0


Was this documentation topic helpful?


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