Skip to content
Back to skills

Saltstack

BSecurity

Covers SaltStack/Salt (3007.x): state files, pillars, grains, execution modules, Salt master/minion architecture, Salt SSH, reactors, beacons, orchestration, and event-driven automation. WHEN: \"SaltStack\", \"Salt\", \"salt-master\", \"salt-minion\", \"state file\", \".sls\", \"pillar\", \"grain\", \"salt-ssh\", \"Salt reactor\", \"Salt beacon\", \"salt-call\", \"salt highstate\".

  • 4 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 24, 2026
devopsbashreactnodedebuggingdatabasesecurity

Works with

  • cli

Security analysis

B75/100
  • criticalAccesses sensitive system or user directories
  • criticalReads or references SSH private keys

Pro shows the line behind each finding and how to fix it

Scanned September 24, 2026

npx -y skills add chrishuffman5/domain-expert --skill saltstack --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Saltstack?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Saltstack
[![Security: B — Skills Directory](https://www.skillsdirectory.com/api/skills/chrishuffman5-saltstack/badge)](https://www.skillsdirectory.com/skills/chrishuffman5-saltstack)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: saltstack
description: "Covers SaltStack/Salt (3007.x): state files, pillars, grains, execution modules, Salt master/minion architecture, Salt SSH, reactors, beacons, orchestration, and event-driven automation. WHEN: \"SaltStack\", \"Salt\", \"salt-master\", \"salt-minion\", \"state file\", \".sls\", \"pillar\", \"grain\", \"salt-ssh\", \"Salt reactor\", \"Salt beacon\", \"salt-call\", \"salt highstate\"."
license: MIT
---

# SaltStack Expert

This skill covers SaltStack (Salt) 3007.x, a configuration management and remote execution platform. Salt uses a master-minion architecture with ZeroMQ for high-speed communication. It excels at managing large fleets (10K+ nodes) with real-time execution.

## Core Architecture

```
┌──────────────────┐
│   Salt Master    │  Stores states, pillars, manages minions
│  (salt-master)   │
│                  │
│  ┌────────────┐  │
│  │ Event Bus  │  │  ZeroMQ pub/sub (port 4505/4506)
│  └──────┬─────┘  │
└─────────┼────────┘
          │
    ┌─────┼─────┐
    │     │     │
┌───▼┐ ┌──▼┐ ┌──▼┐
│Min │ │Min│ │Min│   Minions subscribe to events, execute commands
│ A  │ │ B │ │ C │
└────┘ └───┘ └───┘
```

### Key Concepts

| Concept | Description |
|---|---|
| **State** | YAML `.sls` files declaring desired system configuration |
| **Pillar** | Secure, per-minion data (secrets, config specific to a host) |
| **Grain** | Static minion-side data (OS, CPU, memory — like Facter/Ohai) |
| **Execution Module** | Imperative commands (`pkg.install`, `service.restart`) |
| **State Module** | Declarative resources (`pkg.installed`, `service.running`) |
| **Top File** | Maps states/pillars to minions based on targeting |
| **Reactor** | Event-driven automation (react to events on the bus) |
| **Beacon** | Minion-side monitors that fire events (file changes, process death) |
| **Orchestration** | Multi-minion, ordered workflow execution |
| **Mine** | Share data between minions via the master |

### State File Example

```yaml
# /srv/salt/webserver/init.sls

nginx:
  pkg.installed:
    - version: 1.24.0

  service.running:
    - enable: True
    - watch:
      - file: /etc/nginx/nginx.conf
      - pkg: nginx

/etc/nginx/nginx.conf:
  file.managed:
    - source: salt://webserver/files/nginx.conf.jinja
    - template: jinja
    - user: root
    - group: root
    - mode: '0644'
    - context:
        workers: {{ grains['num_cpus'] * 2 }}
        server_name: {{ pillar['webserver']['hostname'] }}
    - require:
      - pkg: nginx

/var/www/html:
  file.directory:
    - user: www-data
    - group: www-data
    - mode: '0755'
    - makedirs: True
```

### Top File (Targeting)

```yaml
# /srv/salt/top.sls
base:
  '*':                          # All minions
    - common
    - monitoring

  'web*':                       # Glob targeting
    - webserver

  'os:Ubuntu':                  # Grain targeting
    - match: grain
    - ubuntu.packages

  'G@os:CentOS and G@role:db': # Compound targeting
    - match: compound
    - database
```

### Pillar (Secure Data)

```yaml
# /srv/pillar/webserver.sls
webserver:
  hostname: www.example.com
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    ...
  db_password: SuperSecret123

# /srv/pillar/top.sls
base:
  'web*':
    - webserver
```

### Execution vs State

```bash
# Execution (imperative — do this now)
salt '*' pkg.install nginx
salt 'web1' service.restart nginx
salt '*' cmd.run 'uptime'
salt '*' disk.usage

# State (declarative — ensure this is true)
salt '*' state.apply              # Apply all states (highstate)
salt 'web1' state.apply webserver # Apply specific state
salt '*' state.test               # Dry run
```

### Targeting

```bash
# Glob
salt 'web*' test.ping

# Grain (OS, role, etc.)
salt -G 'os:Ubuntu' test.ping

# Pillar
salt -I 'role:webserver' test.ping

# Compound (boolean logic)
salt -C 'G@os:Ubuntu and web*' test.ping

# List
salt -L 'web1,web2,web3' test.ping

# PCRE regex
salt -E 'web[0-9]+\.example\.com' test.ping

# Nodegroup (predefined in master config)
salt -N webservers test.ping
```

### Reactors (Event-Driven)

```yaml
# /etc/salt/master.d/reactor.conf
reactor:
  - 'salt/minion/*/start':        # When any minion connects
    - /srv/reactor/new_minion.sls
  - 'salt/beacon/*/inotify/*':    # When file changes detected
    - /srv/reactor/file_changed.sls

# /srv/reactor/new_minion.sls
apply_base_state:
  local.state.apply:
    - tgt: {{ data['id'] }}
    - arg:
      - common
```

### Orchestration

```yaml
# /srv/salt/orch/deploy.sls
# Ordered, multi-minion deployment

step_1_update_db:
  salt.state:
    - tgt: 'db*'
    - sls: database.migrate

step_2_deploy_app:
  salt.state:
    - tgt: 'web*'
    - sls: myapp.deploy
    - require:
      - salt: step_1_update_db

step_3_verify:
  salt.function:
    - name: http.query
    - tgt: 'web1'
    - arg:
      - https://myapp.example.com/health
    - require:
      - salt: step_2_deploy_app
```

```bash
# Run orchestration
salt-run state.orchestrate orch.deploy
```

### Salt SSH (Agentless)

```bash
# Run commands without minion agent
salt-ssh '*' test.ping
salt-ssh 'web1' state.apply webserver

# Roster file (inventory for salt-ssh)
# /etc/salt/roster
web1:
  host: 10.0.1.10
  user: deploy
  sudo: True
web2:
  host: 10.0.1.11
  user: deploy
  priv: /root/.ssh/id_ed25519
```

### CLI Reference

```bash
# Master management
salt-key --list all           # List accepted/pending/rejected keys
salt-key --accept web3        # Accept a new minion
salt-key --delete web3        # Remove a minion

# Remote execution
salt '*' test.ping            # Connectivity check
salt '*' grains.items         # All grains
salt '*' pillar.items         # All pillar data (careful: shows secrets)
salt '*' state.apply          # Apply highstate
salt '*' state.apply webserver test=True  # Dry run

# Salt-run (master-side)
salt-run manage.status        # Show up/down minions
salt-run state.orchestrate orch.deploy

# Salt-call (minion-side, local execution)
salt-call state.apply --local
salt-call grains.items
```

## Reference Files

- `references/architecture.md` — ZeroMQ transport, event bus, mine system, syndic (multi-master), renderer pipeline, returner system
- `references/best-practices.md` — State organization, pillar design, formula conventions, targeting strategy, security hardening
- `references/diagnostics.md` — Minion connectivity, key management, state compilation errors, pillar rendering issues, event bus debugging

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…