Welcome to Splunk Enterprise 10.4

Validate configuration files

Validate entire configuration files with the properties/{file} endpoint. For more information, see Configuration endpoint descriptions in the REST API Reference.

Index-based Search Targeting

Index-Based Search Targeting is a new enhancement for Federated Search in transparent mode. This feature allows administrators to route search requests directly to specific providers based on index-to-host mappings, providing you with greater control over your search environment. Index-based search targeting provides the following key benefits:

• Enhanced Security: By restricting searches to specific hosts, you minimize the exposure of sensitive information and ensure that query logs are only accessible where necessary.

• Optimized Performance: Reduce system overhead and improve search speeds by eliminating unnecessary requests, which allows your infrastructure to focus resources only on relevant search providers.

This update ensures a more secure, streamlined, and efficient search experience across Federated Search for Splunk environments.

Administrators can now use the following new REST endpoint arguments to configure index-based provider selection for Federated Search for Splunk by specifying which indexes federated search heads can access from federated providers when operating in transparent mode:

• The data/federated/settings/general endpoint: The allowIndexBasedProviderFiltering argument enables index-based filtering for federated providers.

• The data/federated/provider/{federated_provider_name} endpoint: The fedSrchIndexesAllowed argument specifies the indexes that are accessible from each federated provider.

See Federated search endpoint descriptions in the REST API Reference.

Improvements to Edge Processor pipeline previews and updated SPL2 support

The Edge Processor service has been upgraded to improve the accuracy of pipeline previews, allowing full support for additional SPL2 commands such as decrypt and ocsf.

For information about the SPL2 commands and functions that are supported in this release, see Edge Processor pipeline syntax in the Use Edge Processors for Splunk Enterprise manual.

Custom pipeline templates for Edge Processors

You can now create and use custom pipeline templates that are provided through SPL2-based apps.

If an app that contains templates is installed on Splunk Enterprise, those templates become available on the Pipelines page and during the pipeline creation workflow.

See Create custom pipeline templates in the Splunk Developer Guide for information on creating a template and including it in an app.

See Use templates to create pipelines for Edge Processors in the Use Edge Processors for Splunk Enterprise manual for information on creating a pipeline by using a template as a starting point.

Additional match types and configuration options in the lookup command for Edge Processor pipelines

You can now configure lookups that use CIDR matching and wildcard matching. You can also optionally configure lookup matches to be case-sensitive, or require a minimum or maximum number of matches to be returned in the output.

To specify these new configurations, you must manually enter the corresponding command arguments in the pipeline editor.

For information about the supported syntax for the lookup command, see lookup command: Overview, syntax, and usage in the SPL2 Search Reference.

Apply custom command function action for Edge Processor pipelines

To process the incoming data before sending it to a destination, you can now discover, select, and apply custom command functions, which are user-defined SPL2 functions. This is particularly helpful for customers with less experience using SPL2.

See Create and apply a custom command function for the Edge Processor solution in the Use Edge Processors for Splunk Enterprise manual for more information.

Additional new Dashboard Studio features

• Token Manager UI to view all tokens in a dashboard. See Token manager.

• New network graph visualization to visualize entities and the relationships between them. See Network graph.

• Accelerated render option for line charts with improved performance and responsiveness. See Accelerated render line chart example.

Dashboards resource management

New Dashboard Studio custom visualizations framework

Cisco One Look & Feel - Modern Navigation Adoption (GA)

Modern Navigation shifts the traditional top navigation bar to a sleek, side navigation panel complemented by an updated header. Designed to deliver a consistent, accessible experience, Modern Navigation is a part of our overall vision of a cohesive look and feel across Splunk and Cisco products. See Modern navigation UI changes.

You can now perform bulk data moves between SmartStore-backed indexers. Additionally, the Bulk Data Move toolset is now accessible through the Splunk CLI on the Cluster Manager, offering a command-line alternative to the existing REST API for automation and troubleshooting.

See Bulk Data Move for indexer clusters in the Manage indexers and indexer clusters manual.

Using the Topology REST API, admins and applications gain programmatic access to deployment topology and infrastructure introspection data through a unified interface. The endpoints retrieve information using the Splunk Topology sidecar.

The Splunk Topology API provides administrators with an automated, authoritative source for deployment and infrastructure data, streamlines complex workflows like app installations and release upgrades, and eliminates the need for manual input.

See Topology endpoint descriptions in the REST API Reference manual.

Splunk Web now supports the HTTP/2 protocol, which uses multiplexed communication to handle browsing activity in parallel. This significantly improves performance for complex dashboards, simultaneous searches, and multi-tab browsing compared to the sequential processing of HTTP/1.1.

HTTP/2 is supported on Linux and macOS environments.

HTTP/2 is deactivated by default and requires activation.

See Activate HTTP/2 to enhance Splunk Web performance in the Admin manual.

SHA-1 Certificate Support Removed

As of Splunk platform 10, SHA-1 certificates are no longer supported. Customers will need to apply new certificates not using this standard. The Splunk Cloud Monitoring Console and Splunk Enterprise Monitoring Console have previously been updated to report on SHA-1 related warnings and errors raised by the Splunk platform, and customers can continue to use these tools to navigate the change.

App context for Federated Search for Splunk in standard mode

The new update for the app context for Federated Search for Splunk in standard mode introduces a more flexible approach to managing application contexts that gives users a more intuitive experience and simplifies how search contexts are handled. This update allows the federated provider to align with the application context of the search performed on the local federated search head; by default, Splunk platform on standard mode federated providers reflects the context of the user's local search environment.

This update includes a new useAppContextFromSearch parameter for the Splunk REST API {{data/federated/provider/{federated_provider_name}}} endpoint. For more information about this new parameter, see "Federated search endpoint descriptions" in the REST API Reference.

New flag for disabling Splunk Web's Custom REST Endpoints and Custom Mako Templates.

A two new flags have been added to the [feature:appserver_security] stanza of web-features.conf that admins can use to disable the following Splunk Web features:

1. Custom REST Endpoints on the Splunk Web (not Splunk Core) platform can be disabled by setting disable_custom_cherrypy_controllers to true (default: false).
2. Custom Mako Templates shipped by apps (not default templates shipped with Splunk Web) can be disabled by setting disable_custom_mako_templates to true(default: false).

While the behavior does not change in Splunk platform 10.4, this flag has been added to support a future deprecation effort for both of the above features.

Modernize Field administration pages

Splunk field administration pages will update to the latest UI components and libraries, providing a modernized and consistent look and feel with the Splunk platform.

Agent management

Application matching cache

Agent management caches the results of application-to-server-class matching, which reduces the processing time required when agents check in for deployment updates. In large-scale environments with many agents and server classes, this cache improves the performance of the agent management.

Server class configuration viewer

You can view the full configuration details of a server class directly in the agent management interface. You can use this view to verify server class configurations before making changes or to troubleshoot unexpected deployment behavior across your fleet of agents.

Application content previewer

You can preview the contents of a deployment application before distributing it to agents directly in the agent management interface. Use the content previewer to verify that an application contains the expected files and settings, which helps you identify configuration issues before deployment reaches your agents.

Removed parameters from serverclass.conf

The following parameters are removed from the serverclass.conf configuration file in version 10.4: packageTypesFilter, updaterRunningFilter.

Data Management

The new Data Management app now serves as a hub to relevant experiences with a consistent look and feel. Whether you are configuring inputs, monitoring ingestion health, or managing federated connections or datasets, you can now do it all from one location.

Independent client-side TLS certificate configuration for KV Store

In response to public CA policy changes that drop the Client Authentication EKU from default TLS certificates, Splunk now supports independent KV Store client-side TLS configuration through a new [kvstoreSslClientConfig] stanza, allowing separate client and server certificates for KV Store mutual TLS.

Available in Splunk Enterprise 10.4 and applicable for Splunk Enterprise 9.4.10, 10.0.5, and 10.2.2, and Splunk Cloud 10.2.2510.8 and 10.0.2503.13

In 10.4 only: [kvstore] SSL settings are now evaluated per field; partial configurations previously ignored may now apply and should be reviewed before upgrade.

Deprecating TLS 1.0 and TLS 1.1 and removing default support

The Splunk platform is now disabling support by default for TLS 1.0 and TLS 1.1. These protocols remain available should customers require them for migration purposes, but will be completely removed in a future release. TLS 1.2 support remains unchanged and enabled by default alongside the newly-introduced TLS 1.3 support.

Upgrade Splunk Python version from 3.9 to 3.13

Python 3.13 will become the default Python interpreter, with Py3.9 as fallback.

Federated Search for Splunk Transparent Mode Support for IPv6 in Search Head Clusters

Federated Search for Splunk in transparent mode now supports bundle replication to any remote peer within a search head cluster, eliminating the need for direct network access to the remote search head captain. This enhancement enables support for IPv6 environments, such as Microsoft Azure, and configurations where a load balancer serves as the remote gateway.

Role-based Access for Federated Search for Splunk REST APIs

Enhanced security controls are now available for Federated Search for Splunk REST API endpoints, introducing granular, role-based access control (RBAC). Previously, authenticated users could view all federated providers, indexes, and settings. This update shifts access logic to the handler level, ensuring that users only see the resources they are explicitly authorized to access.

Administrators can now enforce precise permissions for individual users, preventing unauthorized information disclosure and ensuring that sensitive infrastructure details remain protected. New specific capabilities have been introduced to manage these permissions effectively, replacing the need for broad, global access. These changes strengthen your security posture and support stricter internal governance, providing a more secure and compliant environment for your Federated Search operations.

The following new capabilities for Federated Search for Splunk are now available in this release:

• edit_federated_indexes
• edit_federated_providers
• list_federated_providers

For more information, see the Table of Splunk Enterprise capabilities in _Securing the Splunk Platform_.

Indexing/Replication Separation

Introduces a new SmartStore-based architecture for Splunk Enterprise indexer clusters that decouples indexing from peer-to-peer replication. Instead of replicating buckets directly between indexers, data and metadata are stored in SmartStore as the system of record, allowing indexers to operate independently.

By removing peer-to-peer replication dependencies, this approach simplifies multisite deployments, improves operational resilience, and enables more flexible scaling of indexers.

Upgrading the backend database for KV Store and KV Service to MongoDB 8.0

Splunk 10.4 release will not include old unsupported MongoDB versions from 4 to 6. If you’re running Splunk 9.x and below, please upgrade to Splunk 10.0 or Splunk 10.2 first as a direct update from MongoDB 4.x / Mongo 6.x to Mongo 8 is unsupported. If you’re on Splunk 10.x, no action is needed as the upgrade to MongoDB 8 will happen automatically with the Splunk upgrade.

Run Splunk Enterprise without root or administrator privileges

Splunk Enterprise 10.4 enforces non-privileged execution across supported operating systems.

Linux: Running Splunk Enterprise as root is no longer supported. The --run-as-root option is honored only with splunk start, splunk stop, and splunk restart.

Windows — new installations: Splunk Enterprise must be configured to run as either a Local Service Account (LSA) or a Domain User Account (DUA) that is not a member of the local Administrators group. The Local System User (LSU) option is no longer available, and installation halts if a selected DUA belongs to the local Administrators group.

Windows — upgrades to 10.4: LSU configurations are migrated to an LSA with ACLs reset appropriately; LSA configurations are retained as-is; DUA configurations are retained provided the account is not in the local Administrators group, and the upgrade is halted otherwise until the DUA is removed from that group.

Workload Management support for Kubernetes

Splunk Enterprise now supports workload management on Kubernetes-based deployments. A new workload management Basic mode lets you apply admission rules on systems such as Kubernetes where cgroups are not available.

You can use admission rules to prevent rogue or resource-intensive searches from interfering with critical workloads. See Use Workload Management on Kubernetes.

Splunk is releasing support for a set of algorithms based on Kyber, Dilithium, and SPHINCS+ to meet the requirements laid out in FIPS 203, 204, and 205 and protect customers from these future quantum threats to cryptography.

TLS 1.3 support

The Splunk platform now supports TLS 1.3 (alongside TLS 1.2) for all public-facing connections, enhancing security with stronger encryption, eliminating outdated cipher suites, and delivering better performance and efficiency. TLS 1.3 will be enabled by default alongside TLS 1.2.

Provider-based Search Targeting with Role-Based Access Control (RBAC) for Federated Search for Splunk

Enhanced Provider Control for Federated Search for Splunk

The new enhancements for Federated Search for Splunk in transparent mode provide administrators and end users with unprecedented control over how data is searched across distributed Splunk environments. These updates ensure that your search operations are more efficient, secure, and tailored to your specific organizational needs.

Federated Search for Splunk allows you to run searches across multiple remote Splunk deployments as if the data were local. In transparent mode, the federated search head acts as a seamless proxy and simplifies the user experience by abstracting the complexity of the underlying remote infrastructure.

1. Targeted provider routing

You can now direct federated searches to specific providers with greater precision:

• User-directed targeting: End users can now explicitly define which federated or remote providers they want to include in their searches, which means that resources are only utilized as necessary.
• Default provider lists: Administrators can configure a default list of providers. If a user does not specify a provider in their search string, the system automatically routes the search to these pre-defined, relevant providers, which maintains a streamlined workflow.

2. Role-Based Access Control (RBAC) for providers

Control over security and governance is now more granular. With the introduction of a new UI-based configuration, administrators can define access controls for individual providers. Now you can specify a default list of providers in the new Providers tab on a role to restrict which roles have the authority to search specific providers, so sensitive data remains accessible only to authorized users.

Benefits

• Optimized performance: By allowing users to target specific providers or defaulting to a curated list, you eliminate unnecessary broadcast traffic. This reduces system overhead and significantly improves search response times across your federated environment.
• Enhanced security and compliance: With new RBAC capabilities, you can enforce strict data governance. By limiting provider access based on user roles, you minimize the risk of unauthorized data exposure and ensure compliance with internal security policies.
• Improved user experience: These features simplify the search process by reducing complexity for end users, while providing administrators with the tools needed to manage a large-scale, multi-deployment environment effectively.

For more information, see:

• “Configure role-based access and search targeting for transparent mode federated providers” in the _Federated Search_ manual.
• The srchFederatedProvidersAllowed and the srchFederatedProvidersDefault arguments for the authorization/roles/{name} endpoint, in “Federated search endpoint descriptions” in the REST API Reference.