5.1 Splunk Roles, Capabilities & Custom Role Design

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:

1. An administrator temporarily assigns the can_delete role to a trusted administrative account.
2. The administrator executes the targeted query ending in | delete.
3. The administrator verifies that subsequent queries return zero matching events.
4. 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.

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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

---

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

1. Navigate to Settings > Roles.
2. Click New Role.
3. In the Inheritance tab, select one or more parent roles to import (e.g., user).
4. In the Capabilities tab, select required granular permissions (e.g., accelerate_search).
5. In the Indexes tab, designate indexes that are permitted (srchIndexesAllowed) and searched by default (srchIndexesDefault).
6. In the Restrictions tab, configure srchFilter strings, concurrent search quotas, and disk space limits.
7. 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.