Study guide
5.1 Splunk Roles, Capabilities & Custom Role Design
Splunk Enterprise Certified Admin SPLK-1003
Track your progress as you read
Finished sections get a check mark.
1 Introduction
About the Splunk Enterprise Certified Admin Exam
2 Chapter 1: Splunk Admin Basics
1.1 Splunk Enterprise Architecture & Core Components
3 Chapter 2: License Management
2.1 License Types, Stacks, Pools & Licensing Architecture 2.2 License Violations, Rolling Window Warnings & Troubleshooting
4 Chapter 3: Splunk Configuration Files
3.1 Splunk Configuration Directory Structure 3.2 Configuration Layering, Precedence & Resolution Rules 3.3 Using btool to Inspect & Debug Configurations
5 Chapter 4: Splunk Indexes
4.1 Index Structure: Directories, Buckets & Bucket Files 4.2 Bucket Types & the Hot-Warm-Cold-Frozen-Thawed Lifecycle 4.3 Checking Index Data Integrity 4.4 indexes.conf Options: Paths, Bucket Sizing & Volumes 4.5 The Fishbucket: File Tracking, CRC Collisions & Re-reading Files 4.6 Applying a Data Retention Policy
6 Chapter 5: Splunk User Management
5.1 Splunk Roles, Capabilities & Custom Role Design 5.2 User Account Administration, Search Restrictions & Limits
7 Chapter 6: Splunk Authentication Management
6.1 Integrating Splunk with LDAP 6.2 Other Authentication Options & Enabling Multifactor Authentication
8 Chapter 7: Getting Data In
7.1 CLI Administration & Basic Data Onboarding Workflows 7.2 Forwarder Types: Universal Forwarder vs. Heavy Forwarder
9 Chapter 8: Distributed Search
8.1 How Distributed Search Works 8.2 Roles of the Search Head and Search Peers 8.3 Configuring Search Peers & Distributed Search Groups 8.4 Search Head Scaling & Search Head Clustering (SHC)
10 Chapter 9: Getting Data In – Staging
9.1 Ingestion Pipeline Stages: Input, Parsing, Merging, Typing & Indexing 9.2 Pipeline Component Placement & Queue Management 9.3 Splunk Input Options
11 Chapter 10: Configuring Forwarders
10.1 Forwarder Setup & outputs.conf Load Balancing 10.2 Indexer Acknowledgment, Data Cloning & Forwarder Routing
12 Chapter 11: Forwarder Management
11.1 Deployment Management & the Deployment Server 11.2 Deployment Apps & Deployment Clients 11.3 Server Classes, Client Grouping & App Deployment Strategies 11.4 Forwarder Management Monitoring & Troubleshooting
13 Chapter 12: Monitor Inputs
12.1 File & Directory Monitoring Mechanics 12.2 Monitor Input Tuning: Whitelists, Blacklists & CRC Settings 12.3 Deploying a Remote Monitor Input, Network Shares & Archives
14 Chapter 13: Network and Scripted Inputs
13.1 Creating Network Inputs: TCP & UDP 13.2 Optional Settings for Network Inputs 13.3 Scripted Inputs & PowerShell Data Collection
15 Chapter 14: Agentless Inputs
14.1 Windows Management Instrumentation (WMI) Inputs 14.2 HTTP Event Collector (HEC) Architecture & Administration
16 Chapter 15: Fine Tuning Inputs
15.1 Input-Phase Processing & Default Metadata Assignment 15.2 Character Set Encoding & Handling Binary Data
17 Chapter 16: Parsing Phase and Data
16.1 Line Breaking & Event Segmentation 16.2 Timestamp Extraction, Time Zones & Clock Skew Handling 16.3 Validating Event Parsing with Data Preview
18 Chapter 17: Manipulating Raw Data
17.1 Transformation Mechanics: props.conf & transforms.conf 17.2 Data Masking, Redaction & SEDCMD 17.3 Event Routing, Dynamic Index Assignment & Filtering to nullQueue
5.1 Splunk Roles, Capabilities & Custom Role Design
Key Takeaways Explain This Topic AI
Splunk Enterprise ships with the admin, power, user, and can_delete roles (plus internal system roles); custom roles are [role_<name>] stanzas in authorize.conf or are built in Settings > Roles.
By default user can search and has accelerate_search but not schedule_search or rtsearch; power adds scheduling and real-time search; admin adds capabilities such as admin_all_objects, indexes_edit, edit_user, and run_debug_commands.
delete_by_keyword belongs only to can_delete, which no account holds by default; the delete command hides events from search but does not free disk space.
importRoles gives a role every capability and allowed index of the roles it imports; roles never take access away, and a user with several roles gets the broadest access.
By default (srchFilterSelecting = true) search filters from multiple or inherited roles are combined with OR; eliminating filters combine with AND.
Last updated: September 2026
Splunk Roles, Capabilities & Custom Role Design
Quick Summary: User authorization in Splunk Enterprise is founded on a role-based access control (RBAC) model governed by authorize.conf . Permissions are determined by the cumulative aggregation of granular capabilities, allowed index lists, search filters, and concurrency quotas assigned directly or inherited hierarchically through parent roles. Understanding built-in roles—especially the isolated operational scope of can_delete —and the precise inheritance resolution rules is vital for constructing secure, least-privilege custom roles.
Splunk Native Roles Architecture
Splunk Enterprise installs with a defined set of predefined native roles. Each built-in role establishes a baseline operational tier, mapping a collection of discrete capabilities to a standard persona:
1. The admin Role
The admin role possesses complete operational authority over the local Splunk Enterprise instance. It holds virtually all capabilities required to manage users, configure authentication strategies, define data inputs, install and manage applications, manage indexes, inspect system logs, and modify server configuration files. However, by default, the admin role does not hold the capability to delete indexed data.
2. The power Role
The power role is tailored for advanced analysts, power users, and departmental content creators. Key permissions include:
Creating, editing, and sharing knowledge objects (dashboards, reports, event types, field extractions, lookups) across the application context ( manage_own_objects and sharing permissions).
Scheduling saved searches, alerts, and report generation ( schedule_search ).
Creating and maintaining alerts for departmental teams.
Higher search job and disk quotas than the user role (500 MB srchDiskQuota by default).
Boundary: Power users cannot modify data ingestion pipelines, edit system indexes, manage user accounts, or configure external authentication.
3. The user Role
The user role represents the standard operational persona for knowledge workers and tier-1 analysts:
Running ad-hoc searches across permitted indexes ( search ).
Creating private knowledge objects (saved searches, private dashboards, private lookups).
Boundary: Users cannot share knowledge objects globally or with app users by default unless granted explicit write permissions. By default they get srchJobsQuota = 3 and srchDiskQuota = 100 MB, and they lack schedule_search , so they cannot schedule searches or create alerts.
4. The can_delete Role & Data Scrubbing Mechanics
The can_delete role is a specialized, restricted administrative role whose sole purpose is to hold the delete_by_keyword capability. By default, no user account—including the default admin user—is assigned to the can_delete role upon installation.
How the | delete Command Operates
When an administrator pipes search results to the delete operator ( index=security sourcetype=firewall credit_card=* | delete ):
Splunk does not physically purge or overwrite the raw data chunks stored in the bucket's compressed rawdata journal file ( journal.zst or journal.gz ).
Instead, Splunk marks the matching events as deleted in the index so that searches no longer return them.
Subsequent searches executed across those indexes will skip the masked events, rendering them invisible to normal SPL queries.
The underlying disk space is only reclaimed when the entire bucket rolls to frozen and is purged according to data retention policies in indexes.conf .
Operational Data Scrubbing Workflow
To comply with data privacy regulations (such as GDPR or PCI-DSS) when sensitive information is accidentally ingested:
An administrator temporarily assigns the can_delete role to a trusted administrative account.
The administrator executes the targeted query ending in | delete .
The administrator verifies that subsequent queries return zero matching events.
Critical Step: The administrator immediately unassigns the can_delete role from their account to prevent accidental data masking in future sessions.
5. Specialized Internal Roles
splunk-system-role : An internal system role used exclusively by internal processes ( splunkd ) to perform background indexing, replication, search dispatching, and system introspection. It should never be manually assigned to human users.
Native Roles Comparison Matrix
Splunk's capability reference shows which capabilities each built-in role holds by default. The quotas below are the spec defaults you can rely on. Exact values for power and admin live in $SPLUNK_HOME/etc/system/default/authorize.conf , so confirm them with splunk btool authorize list role_power --debug .
Attribute / Capability admin power user can_delete
Primary Function System administration & configuration Shares knowledge objects, schedules searches and alerts Runs searches, owns private objects Holds only delete_by_keyword
- srchJobsQuota Higher than user (check with btool) Higher than user (check with btool) 3 (the spec default) n/a
- srchDiskQuota 10,000 MB 500 MB 100 MB (spec default) n/a
- Internal indexes ( _* ) searchable by default Yes No No n/a
- search , accelerate_search , schedule_rtsearch , list_inputs Yes Yes Yes No
- schedule_search , rtsearch Yes Yes No No
accelerate_datamodel , admin_all_objects , indexes_edit , edit_user , edit_roles , run_debug_commands Yes No No No
delete_by_keyword No No No Yes
Exam note: schedule_rtsearch is listed for every built-in role, but a scheduled real-time search also needs schedule_search and rtsearch . A plain user therefore cannot schedule one.
Role Inheritance Architecture
Splunk supports hierarchical role inheritance using the importRoles directive within authorize.conf . When a custom role imports one or more parent roles, it inherits their permissions according to specific resolution rules: [role_soc_lead]
- importRoles = power;soc_tier1
- schedule_search = enabled
- accelerate_datamodel = enabled
- srchJobsQuota = 12
- srchDiskQuota = 1000
- Inheritance Resolution Rules
When a child role imports multiple parent roles, Splunk computes effective permissions across different parameter categories using distinct aggregation models:
Capabilities (Additive Union): Capabilities are strictly cumulative. If Role A possesses schedule_search and imports Role B possessing accelerate_datamodel , the resulting role possesses both schedule_search and accelerate_datamodel . An imported capability cannot be revoked or "subtracted" by a child role.
Accessible Indexes ( srchIndexesAllowed - Additive Union): The list of indexes a user is permitted to search expands as a mathematical union of all indexes defined in the child role and all inherited parent roles. For example, if Role A allows index=web and Role B allows index=security , the user can search both web and security .
Default Indexes ( srchIndexesDefault - Additive Union): The list of default indexes (searched when no index= directive is in the SPL query) is combined as a union across all inherited and locally specified default indexes.
Search Job Concurrency Quotas (Broadest Wins): For srchJobsQuota (historical searches) and rtSrchJobsQuota (real-time searches), Splunk evaluates all inherited values and the locally defined value, assigning the maximum (highest) integer . If Role A defines srchJobsQuota = 3 and Role B defines srchJobsQuota = 8 , the user is granted 8 concurrent searches. Quotas do not sum together.
Dispatch Disk Storage Quotas ( srchDiskQuota - Highest Value Wins): Disk quotas for search artifacts in $SPLUNK_HOME/var/run/splunk/dispatch resolve to the maximum (highest) value among all inherited and local definitions.
Search Filters ( srchFilter ): Roles never take access away, and filters combine according to srchFilterSelecting in authorize.conf (default true ):
Selecting filters (default): filters from the roles a user holds, including inherited roles, are joined with OR , so the user can see anything that at least one filter selects.
Eliminating filters ( srchFilterSelecting = false ): filters are joined with AND , so each one removes more results.
A role can clear inherited filters by setting srchFilter = * , as the admin role does.
Core Splunk Capabilities Deep Dive
Capabilities are the building blocks of authorization, and Splunk Enterprise defines a long list of them in authorize.conf.spec . Understanding the operational impact and security risk of core capabilities is essential for certification and administrative governance:
Critical Administrative & Operational Capabilities
Capability Name Operational Action Enabled Security Risk Level Default Holders / Recommended Assignment
search Allows the user to execute basic ad-hoc search queries and spawn search jobs. Low Assigned to all roles ( user , power , admin ).
schedule_search Lets the user schedule saved searches, create and update alerts, review triggered alerts, and use the sendemail command. Medium power and admin by default; not user .
accelerate_datamodel Allows enabling and configuring Data Model Acceleration (DMA), creating persistent .tsidx acceleration summaries on indexers. High Senior power users, data engineers, ES administrators. Can heavily load indexer disk I/O.
admin_all_objects Bypasses all permissions, object locks, and Access Control Lists (ACLs) across every application context. Allows reassigning orphaned objects. Critical Restricted strictly to admin . Should never be granted to standard or power roles.
indexes_edit Allows creating, modifying, disabling, and deleting indexes in indexes.conf and via REST API. Critical Restricted strictly to admin . Unauthorized access can cause data corruption or data loss.
edit_user Allows creating, editing, unlocking, and deleting user accounts and assigning roles. Critical Restricted to identity administrators and admin .
run_debug_commands Lets a user run debugging search commands, for example summarize . (Other commands have their own capabilities, such as run_dump for dump .) High admin by default.
delete_by_keyword Enables the delete search command, which marks events as deleted so searches no longer return them (disk space is not reclaimed). High Only the can_delete role; not even admin has it by default.
accelerate_search Enables report acceleration (also requires schedule_search ). Medium Listed for user , power , and admin by default.
schedule_rtsearch Lets the user schedule real-time saved searches; schedule_search and rtsearch are also required. High Listed for all three built-in roles, but only roles that also have rtsearch and schedule_search can use it.
Designing Custom Roles via Splunk Web and authorize.conf
Administrators can implement custom roles either through the Splunk Web graphical interface or by defining configuration stanzas in authorize.conf .
Method 1: Creating Roles in Splunk Web
Navigate to Settings > Roles .
Click New Role .
In the Inheritance tab, select one or more parent roles to import (e.g., user ).
In the Capabilities tab, select required granular permissions (e.g., accelerate_search ).
In the Indexes tab, designate indexes that are permitted ( srchIndexesAllowed ) and searched by default ( srchIndexesDefault ).
In the Restrictions tab, configure srchFilter strings, concurrent search quotas, and disk space limits.
Click Save .
Method 2: Direct Configuration in authorize.conf
For configuration-managed environments, deployment servers, and Search Head Clusters, custom roles are declared in $SPLUNK_HOME/etc/apps/<custom_app>/local/authorize.conf or $SPLUNK_HOME/etc/system/local/authorize.conf .
- Production Example 1: Tier-1 Security Operations Center Analyst [role_soc_tier1]
- # Inherit baseline user search rights
- importRoles = user
- # Restrict index visibility strictly to security telemetry
- srchIndexesAllowed = security;firewall;wineventlog;ids
- srchIndexesDefault = security
- # Search restriction: Exclude noisy debug events
- srchFilter = sourcetype!=cisco:asa:debug AND sourcetype!=palo:traffic:drop
- # Moderate search quotas (0 would mean UNLIMITED, never "none")
- srchJobsQuota = 4
- srchDiskQuota = 500
- # No real-time searches: simply do not grant the rtsearch capability
- Production Example 2: Data Model Acceleration Engineer [role_dma_engineer]
- # Inherit power user rights to share knowledge objects
- importRoles = power
- # Enable Data Model Acceleration and report acceleration
- accelerate_datamodel = enabled
- accelerate_search = enabled
- # Permit querying all non-internal indexes
- srchIndexesAllowed = *
- srchIndexesDefault = main
- # Increased resource quotas to build large summaries
- srchJobsQuota = 10
- srchDiskQuota = 5000
- Production Example 3: External Compliance Auditor [role_compliance_auditor]
- # Inherit user baseline
- importRoles = user
- # Read access to audit and system event logs
- srchIndexesAllowed = _audit;_internal;compliance
- srchIndexesDefault = compliance
- # Row-level scoping: Only view finalized records
- srchFilter = audit_status=finalized
- # Real-time search is prevented by NOT granting rtsearch (user does not have it)
- srchJobsQuota = 2
- srchDiskQuota = 250
- Configuration Inspection & Troubleshooting with btool
Because roles can be defined across multiple system, app, and user directories, administrators must use splunk btool to determine the active, consolidated role definition: # Inspect the consolidated authorize.conf definition for a custom role
splunk btool authorize list role_soc_tier1 --debug
- # Verify which stanza provides a specific capability
- splunk btool authorize list --debug | grep -B 2 -A 5 "accelerate_datamodel = enabled"
- Administrative Traps & Architecture Anti-Patterns
- Anti-Pattern 1: Granting can_delete Permanently to Administrator Accounts
Failure Mechanism: Leaving can_delete permanently attached to an administrator's day-to-day account means that a syntax typo or poorly scoped search piped to | delete will immediately mask thousands or millions of production events.
Remediation: Keep can_delete detached from all accounts. Only assign it during scheduled maintenance windows, run the specific | delete query, and unassign the role immediately.
Anti-Pattern 2: Granting admin_all_objects to Power Users to Resolve Permission Conflicts
Failure Mechanism: When an analyst cannot edit another user's private dashboard or alert, administrators sometimes grant admin_all_objects . This grants that user total control over all system configurations, credentials, passwords, and apps, effectively elevating them to full administrator.
Remediation: Transfer ownership of the specific orphaned object using Settings > All Configurations > Reassign Knowledge Objects , or adjust the object's permissions in Splunk Web to grant app-level write permissions.
Anti-Pattern 3: Uncontrolled Data Model Acceleration Rights
Failure Mechanism: Assigning accelerate_datamodel loosely allows users to accelerate data models with 1-year summary ranges spanning high-volume indexes. Indexers will experience severe disk I/O saturation and storage exhaustion.
Remediation: Restrict accelerate_datamodel to dedicated data engineers and monitor acceleration status and size under Settings > Data models and in the Monitoring Console's search dashboards.