SaltStackEnterpriseHelp-V6 1 0 October

SaltStack Enterprise Documentation
Release 6.1.0
SaltStack, Inc.
October 30, 2019 at 11:56:13 MDT

CONTENTS
1 SaltStack Enterprise 3
2 Architecture 5
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Enterprise API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.4 Temporary data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.5 Enterprise Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.6 Salt Master Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Enterprise Console 9
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 How to use Enterprise Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Accessing Enterprise Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Adjusting your preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 Changing your password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.4 Opening product documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1 Supported web browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2 User preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.3 Workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Minions and targets 13

4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 How to use minions and targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1 Viewing minion details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2 Running a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3 Running a command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.4 Defining a new target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.5 Assigning pillar to a target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1 Minion presence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.2 Key States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.3 Target settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Minion Keys 21
i
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2 How to manage minion keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1 Accepting a new minion key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.2 Rejecting minion keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.3 Deleting minion keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Prerequisites to accepting keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.2 Key States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6 Enterprise Proxy 25
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.1 Difference between Proxy Minions and Enterprise Proxy . . . . . . . . . . . . . . . . . . . . 25
6.2 How to use the Enterprise Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2.1 Configuring Enterprise Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.2 Validate proxy key acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2.3 Configuring the Proxy Warden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2.4 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3.2 How the Proxy Warden operates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7 Activity 33
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2 How to use the Activity workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2.1 Pausing an operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2.2 Stopping an operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2.3 Skipping an operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2.4 Filtering by time range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2.5 Changing table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3.1 Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8 Jobs 37
8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.2 How to use Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.2.1 Opening the jobs workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.2.2 Creating a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.2.3 Running a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.2.4 Viewing job returns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.2.5 Editing a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.2.6 Defining job permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.3.1 Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.3.3 Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.3.4 Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.3.5 Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.3.6 Test (dry run) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9 Job Returns 43
ii
9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.2 How to view job results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.2.1 Viewing job results by minion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.2.2 Viewing job results by time of completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.2.3 Downloading job results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.3.1 Job return information fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.3.2 Custom Outputters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10 Schedules 49
10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.2 How to use Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.2.1 Creating a schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.2.2 Checking job status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.2.3 Modifying a schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.3.1 Schedule settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.3.2 Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
10.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11 Directory Service 53
11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.2 How to use Directory Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.2.1 Creating a Directory Service connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.2.2 Enabling groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
11.2.3 Enabling users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
11.2.4 Removing groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.2.5 Removing users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.2.6 Editing Directory Service connection settings . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.2.7 Deleting a Directory Service connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.3.1 Directory Service information fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.3.2 Authentication process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
11.3.3 Archived groups and users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
11.3.4 Nested groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
11.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12 Local Users 61
12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.2 How to manage local users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.2.1 Creating a Local User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.2.2 Cloning a Local User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.2.3 Changing user settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
12.2.4 Changing root password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
12.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
12.3.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
12.3.2 Master key authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
12.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
13 Roles and Permissions 63

13.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.2 How to use the Roles workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.2.1 Creating a role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.2.2 Cloning a role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
iii
13.2.3 Editing a role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
13.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.3.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.3.2 Resource access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
13.3.3 Difference between permitted tasks and resource access . . . . . . . . . . . . . . . . . . . . 69
13.3.4 Types of roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
14 Advanced permissions 71
14.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
14.2 How to set Advanced permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
14.2.1 Defining advanced permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
14.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
14.3.1 Permission types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
14.3.2 Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
14.3.3 Resource access in the API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
14.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
15 Built-in roles default settings 77

15.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
15.2 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
15.2.1 User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
15.2.2 Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
15.2.3 Superuser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
15.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
16 Reports 79
16.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
16.2 How to use Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
16.2.1 Viewing reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
16.2.2 Downloading reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
16.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
16.3.1 Types of reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
16.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
17 Pillars 83
17.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
17.2 How to use Pillars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
17.2.1 Creating a pillar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
17.2.2 Assigning pillar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
17.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
17.3.1 Pillars and the All Minions target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
17.3.2 Value precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
17.3.3 Pillar data format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
17.3.4 Pillar dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
17.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
18 File Server 87
18.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
18.2 How to use the file server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
18.2.1 Creating a file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
18.2.2 Cloning a file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
18.2.3 Deleting a file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
18.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
18.3.1 Integration with existing file servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
iv
18.3.2 Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
18.3.3 File server access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
18.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
19 SecOps Compliance 91
19.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
19.1.1 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
19.1.2 Assessments and remediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
19.1.3 Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
19.2 How to use SecOps Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
19.2.1 Building a policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
19.2.2 Running an assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
19.2.3 Remediating all checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
19.2.4 Adding exemptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
19.2.5 Defining SecOps Compliance permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
19.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
19.3.1 The SecOps Compliance content library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
19.3.2 Compliance policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
19.3.3 Activity status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
19.3.4 Assessment results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
19.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
20 SecOps Compliance Custom Content 101

20.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
20.2 How to use custom content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
20.2.1 Initializing the SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
20.2.2 Creating custom checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
20.2.3 Creating custom benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
20.2.4 Testing custom content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
20.2.5 Building the custom content library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
20.2.6 Importing custom content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
20.2.7 Deleting custom checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
20.2.8 Deleting custom benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
20.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
20.3.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
20.3.2 Folders and files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
20.3.3 Custom content library files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
20.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
21 SecOps Vulnerability 109

21.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
21.2 How to use SecOps Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
21.2.1 Viewing your vulnerability dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
21.2.2 Creating a policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
21.2.3 Running a vulnerability scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
21.2.4 Viewing assessment results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
21.2.5 Remediating all Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
21.2.6 Adding exemptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
21.2.7 Defining SecOps Vulnerability permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
21.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
21.3.1 Vulnerability policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
21.3.2 Activity status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
21.3.3 Vulnerability dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
21.3.4 Assessment results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
v
21.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
22 SecOps Architecture 117

22.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
22.1.1 SecOps content libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
22.2 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
23 SaltStack Enterprise Configuration 119

23.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
23.2 How to configure SaltStack Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
23.2.1 Generating default configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
23.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
23.3.1 Enterprise API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
23.3.2 Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
23.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
24 Master Plugin 121

24.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
24.2 How to configure the Master Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
24.2.1 Installing the master plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
24.2.2 Setting up public key authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
24.2.3 Setting up username authentication (deprecated) . . . . . . . . . . . . . . . . . . . . . . . . 122
24.2.4 Generating a default Master Plugin configuration . . . . . . . . . . . . . . . . . . . . . . . . 122
24.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
24.3.1 SSL settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
24.3.2 PG JSON Return settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
24.3.3 Directories settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
24.3.4 Key states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
24.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
25 Configuration file example 125

25.1 Generating a default RaaS configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
25.2 Example Enterprise API configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
25.2.1 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
26 Samples 133
26.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
26.2 How to use SaltStack Enterprise samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
26.3 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
26.3.1 Default targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
26.3.2 Sample jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
26.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
27 Security Guidelines 137

27.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
27.2 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
27.2.1 Automatic logout if inactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
27.2.2 Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
27.2.3 Encrypted credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
27.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
28 Enterprise API (eAPI) RPC Endpoint Documentation 139

28.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
28.2 API syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
28.3 Using the API with Curl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
vi
28.4 Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
28.4.1 API Permission values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
28.5 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
28.6 RPC over WebSockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
28.7 HTTP Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
28.8 RPC Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
28.8.1 admin interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
28.8.2 api interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
28.8.3 audit interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
28.8.4 auth interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
28.8.5 background_jobs interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
28.8.6 cloud interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
28.8.7 cmd interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
28.8.8 conf interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
28.8.9 formula interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
28.8.10 fs interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
28.8.11 job interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
28.8.12 kv interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
28.8.13 license interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
28.8.14 master interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
28.8.15 masterfs interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
28.8.16 minions interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
28.8.17 pillar interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
28.8.18 remote interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
28.8.19 ret interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
28.8.20 roster interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
28.8.21 schedule interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
28.8.22 sec interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
28.8.23 settings interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
28.8.24 stats interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
28.8.25 test interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
28.8.26 tgt interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
28.8.27 vman interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
29 Troubleshooting 227
29.1 Pages not Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
29.2 Some Minions Are Not Running Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
29.3 Job Results Take a Few Minutes to Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
29.4 Button Labels are Truncated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
29.5 Generate a Bug Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
29.6 Additional Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
vii
viii
SaltStack Enterprise Documentation, Release 6.1.0
Contents:
CONTENTS 1
2 CONTENTS
CHAPTER
ONE
SALTSTACK ENTERPRISE
SaltStack Enterprise extends your Salt infrastructure with advanced job management and execution, role-based se-
curity, reporting, and more. SaltStack Enterprise adds the following components to your Salt infrastructure:
• Enterprise API
• Enterprise Console
• Salt master plug-in
Enterprise API is much more than a command and control interface. Enterprise API provides a remote fileserver,
external pillar, job return database, and sophisticated role-based security with external LDAP authentication.
Enterprise Console provides a visual interface that simplifies management and reporting. Enterprise Console inte-
grates directly with Enterprise API to enable job execution and history, display presence, and enable visual manage-
ment of the Enterprise API file server, pillar store, and role-based security.
3
The Salt master plug-in is installed on each Salt master to enable integration with Enterprise API. The Salt master
plug-in enables each Salt master to receive jobs, files, and pillar data from Enterprise API, and send grains, job returns,
and events to Enterprise API.
4 Chapter 1. SaltStack Enterprise

CHAPTER
TWO
ARCHITECTURE
2.1 Overview
The following diagram lists the primary components of SaltStack Enterprise, along with the integration points be-
tween each.
SaltStack Enterprise’s primary components are described in detail below.
2.1.1 Enterprise API
Enterprise API is the central component in SaltStack Enterprise. Enterprise API provides RPC endpoints to receive
management commands from Enterprise Console, as well as RPC control endpoints to interface with connected Salt
Masters. All communication is sent using RPC API calls over WebSockets or HTTP(s).
For more on Enterprise API, see RPC Endpoint Documentation.
Role Based Access Control (RBAC)
Role Based Access Control is at the core of the Enterprise API. All connections and operations are processed through
the role-based security system to provide granular control of your Salt environment. If an operation is allowed,
Enterprise API forwards the command through the secure Command and Control interface to Salt masters. Since all
access goes through the Enterprise API role-based security system, you do not need to set up individual accounts or
LDAP integration points on each Salt Master. Enterprise API provides the central management point for all access.
5
For more on RBAC, see Roles and permissions.
2.1.2 LDAP
Lightweight Directory Access Protocol (LDAP) in Enterprise API is used to import user access policy settings such
as authentication details from your server. This means you can import users and groups by synchronizing Enterprise
API with your LDAP server. This also allows for Active Directory (AD) integration.
For more on using LDAP in SaltStack Enterprise, see LDAP.
2.1.3 Database
Enterprise API uses a database to store Salt Minion data, job returns, event data, files and pillar data, local user
accounts, as well as additional settings for Enterprise Console.
2.1.4 Temporary data storage
Enterprise API stores certain types of data, such as cached data, in temporary storage. It also uses temporary data
storage to distribute queued work to background workers. For more on background workers, see Background worker
options (https://support.saltstack.com/hc/en-us/articles/360020836791-Background-Worker-Options).
2.1.5 Enterprise Console
Enterprise Console is a web application that provides the front end to Enterprise API. Enterprise Console interfaces
directly with Enterprise API to enable simple management of all systems in your environment.
Note: To take advantage of the Enterprise Console’s full range of features, use the latest version of one of the
following web browsers.
• Google Chrome
• Mozilla Firefox
For more on Enterprise Console, see Enterprise Console.
2.1.6 Salt Master Plugin
The Salt Master plugin installed on the Salt Master allows the Salt Master to communicate with the SaltStack Enter-
prise backend server. This allows the Salt Master to access processes taking place, as well as external files and pillar
data, stored on the backend server.
The plugin uses the existing extension points provided by Salt for integration. For example, job returns are collected
using a master-side Salt external job cache, and the Enterprise API file server uses a Salt fileserver plugin.
For more on the master plugin, see Master Plugin.
6 Chapter 2. Architecture
Job system architecture
The following diagram illustrates the process that takes place when a job run is initiated in Enterprise Console.
The job system architecture is described in detail below.

When a job run is initiated in Enterprise Console, an RPC call is sent to Enterprise API that contains the job, target,
and details on the user who is initiating the job. The request is evaluated against RBAC settings in Enterprise API,
and if the user has sufficient privileges to run the job against the target, the request is processed.
Jobs are used to run remote execution tasks, apply states, and start Salt runners. For more on jobs, see Jobs. A target
is the group of minions, masters, or a single master that a job’s Salt command applies to. For more on targets, see
Targets.
Note that Enterprise API pre-filters the targets and jobs displayed to users in Enterprise Console. Therefore, a user
who can see a target and a job can likely also run the job on the given target. Each request is still processed through
role-based security before it is executed.
Enterprise API then places the job in the job queue. Each Salt Master contacts the Enterprise API at a configurable
interval during which a check is made for new jobs.
If a job is available, it is retrieved and each Salt Master executes the command contained in the job using the typical
command execution process.
Each Salt Master is configured to use an external job cache to send job results directly to Enterprise API. This job
cache is configured on the Salt Master, therefore job results are forwarded to Enterprise API after they are received
2.1. Overview 7
by each Salt Master. For more on the external job cache, see Storing job results in an external system (https://docs.
saltstack.com/en/latest/topics/jobs/external_cache.html).
2.2 See also

• Users
• Roles and Permissions
• LDAP
• Master Plugin
• Jobs
• Targets
• RPC Endpoint Documentation
8 Chapter 2. Architecture
CHAPTER
THREE
ENTERPRISE CONSOLE
3.1 Overview
The Enterprise Console is a web application that provides the front end to Enterprise API. It is the central interface
to manage minions, users, roles, jobs, and more. Management tasks are available through different workspaces.
Note: Manual page refreshes might be required when changing views or performing operations. If the view does
not change after you perform an action, reload the page.
3.2 How to use Enterprise Console
Enterprise Console is used to manage your infrastructure in a web browser interface. In Enterprise Console you
can complete tasks through different workspaces, view documentation, and change your user preferences, as well
as your password.
Note: Some tasks are available through Enterprise API only. See Enterprise API .
3.2.1 Accessing Enterprise Console
1. In a web browser, go to the SaltStack Enterprise URL provided by your administrator. For a list of supported
browsers, see Supported web browsers.
2. In the login page, enter your username and password and click Log In.
Note: If you enter incorrect credentials, the page might load for up to 30 seconds before you are prompted
to retry. For assistance, contact your administrator.
3.2.2 Adjusting your preferences
1. In any workspace in Enterprise Console, click the menu in the upper right and select Preferences.
2. Update your preferences as required and click Save.
For a description of available preferences, see User preferences.
9
3.2.3 Changing your password
1. In any workspace in Enterprise Console, click the menu in the upper right and select Preferences.
2. Under Update Password, enter the new password in the password field, and again to confirm.
3. Click Save.
3.2.4 Opening product documentation
In any workspace in Enterprise Console, click Help in the upper right and select Help Documentation.
The documentation opens in a new tab.
3.3 Reference
3.3.1 Supported web browsers
To take advantage of the Enterprise Console’s full range of features, use the latest version of one of the following
web browsers.
• Google Chrome
• Mozilla Firefox
3.3.2 User preferences
Under Preferences, you can adjust the following options:
10 Chapter 3. Enterprise Console

Option Description
Log out after You will be logged out automatically after this length of inactivity.
Theme Choose from the dark or light theme.
3.3.3 Workspaces
Workspace Description
Minions View minion details, run jobs, and save new targets.
You can also use run jobs, accept or reject keys, as well
as assign a role or pillar to a target. For more on min-
ions and targets, see Minions and targets.
Activity Monitor the status of jobs and other operations. You
can pause or stop operations that are in progress, or
skip upcoming iterations of a scheduled task. For more
on the activity workspace see Activity.
Elements Build and create the components that can be reused in
your infrastructure, including the following:
• Jobs
• Pillars
• Activity
• File Server
SecOps Compliance | Manage the security compliance posture for all the systems in your
environment. For more on SecOps Compliance, see SecOps Compliance.
Note: SecOps Compliance is an add-on to SaltStack Enterprise, and a license is required.

Administration Manage the users, permissions, and preferences for
your SaltStack Enterprise deployment. For more on
Administration, see the following:
• Local users
• Directory Service
• Roles and permissions
3.4 See also
• Introduction to SaltStack Enterprise

• Architecture
3.4. See also 11

12 Chapter 3. Enterprise Console

CHAPTER
FOUR
MINIONS AND TARGETS
4.1 Overview
The Minions workspace is used to view minion details, run jobs or commands, define new targets, and adjust target
settings such as attached pillars.
The workspace includes a list of Salt Minions. Minions are nodes running the Salt Minion service, which can listen
to commands from a master and perform the requested tasks. Salt Masters can themselves run the minion service
to aid in management of the machine running the Salt Master service.
The left panel of the workspace includes a list of targets. A target is the group of minions, masters, or a single master
that a job’s Salt command applies to. Targets can contain Salt Minions that are connected to any Salt Master in your
environment. You can attach pillar data to different targets. Pillars are structures of data defined on the Salt Master
and passed through to one or more minions, using targets. They allow confidential, targeted data to be securely sent
only to the relevant minion. See Pillar.
By default, when you open the workspace, the All Minions target is active. This is a list of all minions you have
permission to access.
SaltStack Enterprise includes a Run Command control that allows you to run a single command without defining
a reusable job. This is useful for executing commands quickly, or running one-off jobs that are not part of your
everyday workflow, for example when troubleshooting, or during initial configuration. For more information, see
Running a command.
4.2 How to use minions and targets
The Minions workspace is used to view minion details, run jobs or commands, save new targets, and attach pillar
data to targets. For more on jobs, see Jobs.
The workspace also includes the ability to search for a minion, or to sort minions based on ID or other system
properties (referred to as grains).
4.2.1 Viewing minion details
1. In the Minions workspace, select a minion ID from the id column.

2. In the minion details page, you can view a list of grains, or information about the minion.
3. Select the Activity tab to view the minion’s job history. For more on jobs, see Jobs.
For more on minion Presence and Key state, see Reference.
13
Downloading minion data
1. In the Minions workspace, select all minions you want to include in the minion data report.
2. Click More actions.
3. In the menu, under Download table, select the required format to begin the download.
Searching for a minion
1. In the Minions workspace, click the filter button for the column you want to search.
2. Start typing the search criteria to see the rows filter instantly. For example, you might search for a minion ID
in the Minion column.
Note: You can also click the column name once to sort the rows in descending order. Click again to reverse
the order.
Changing table columns
1. Click the Column button in the lower left corner.
2. In the menu, select or deselect columns you want to include in the table view.
4.2.2 Running a job
1. In the left panel, select the target you want to run the job against.
14 Chapter 4. Minions and targets

The name of the currently selected target shows above the minions list.
Note: Targets are dynamic, and new minions are automatically added to any matching target definition.
Make sure to review the minions included in a target before you run a job.
2. Click Run job.

3. In the confirmation dialog, select the job you want to run and confirm the correct target is selected.
Note: You can run only jobs that are defined for the selected target, or that are not defined for any specific
target.
4. Select additional options as needed and click Run now.

For more on jobs and the different options available when running a job, see Jobs.
4.2.3 Running a command
1. In the left panel, select the target you want to run the command against.
2. Click Run Command.
4.2. How to use minions and targets 15

3. In the Run Command dialog, confirm the correct command and target are selected, then select a function.
Note: If you select the salt-run command, you can choose to run the command on all masters, or on a
specific master. This is known as a Salt runner. For more on Salt runners, see Salt runners.
Include any arguments as needed. For more on Salt commands and functions, see Jobs.
4. Click Run Command.
The command is executed as a job. You can track its progress and results as for other jobs in SaltStack Enter-
prise. See Job Returns.
4.2.4 Defining a new target
1. In the Minions workspace, click Create target.

2. Enter a target name and define settings for the types of nodes you want to target. See Target criteria.
Note: If you select Compound as the first criterion, you must follow the targeting syntax included in the ,
and you must include any secondary criteria in the compound target definition. SaltStack Enterprise will not
allow you to add any other criteria in the target editor. For more on compound targeting, see Target criteria.
3. When complete, click Save.
Defining a simple list target
1. In the Minions workspace, select all minions to include in the list and click Create target.

Note: Filtering or sorting your minions can be useful for defining a list. See ‘Filtering and sorting the
minion list‘_.
The selected list is included as a criterion.

2. Enter a target name and define any additional target settings. See Target criteria.
3. When complete, click Save.
4.2.5 Assigning pillar to a target
1. In the Minions workspace, select a target.

2. Click More actions.
3. In the menu, click Attach Pillar.
4. In the dialog, select the pillars you want to apply to the target.
In addition to selecting a pillar, select Refresh pillar to make the pillar available to the selected target immedi-
ately.
5. Click Update Target.
The selected pillar data is now available to all minions in the target.
Note: You can also assign a pillar to a target in the Pillars Workspace. See Pillar.
4.3 Reference
4.3.1 Minion presence
The Presence column indicates if SaltStack Enterprise has received any job data from the minion recently, within a
defined interval called raas_presence_expiration. By default, this interval is set to 3600 seconds. Presence
can provide an indicator of machine health by using the Presence beacon installed on minions.
If the Presence beacon is in place, minions send periodic status payloads to their masters, which SaltStack Enterprise
then retrieves, influencing the status displayed in the Presence column.
Beacons are used to monitor non-Salt processes. When monitored activity occurs, an event is sent that can be
configured to trigger a reactor. For more on beacons, see Salt beacon reference (https://docs.saltstack.com/en/latest/
topics/beacons/index.html).
Note: You can check which beacons are installed and active on a minion by running a job with beacons.list
on a minion’s respective target. For more on jobs, see Jobs.
SaltStack Enterprise provides the following Presence statuses.

Unknown SaltStack Enterprise has never seen a response from the minion. This is the default status for newly-
connected minions. Once minions have received a command, the status updates to Present.
Present SaltStack Enterprise has seen responses from the minion within the last raas_presence_expiration
interval, set to 3600 seconds by default.
4.3. Reference 17
Disconnected SaltStack Enterprise has seen a response from the minion, but not within the last
raas_presence_expiration interval.
4.3.2 Key States
Key states display in the Key state column of the Minions workspace.
On initial connection, a Salt Minion sends its public key to the Salt Master, which the master can accept, reject, or
deny. SaltStack Enterprise displays keys with one of the following statuses.
Accepted Key was accepted and the minion can communicate with the Salt Master.
Pending Key is not accepted or denied. In this state, connections are not accepted from the Salt Minion and jobs
are not executed.
Rejected Key was explicitly rejected using the Reject Key command. In this state, connections are not accepted
from the Salt Minion and jobs are not executed.
Denied Key was rejected automatically by the Salt Master. This occurs when a minion has a duplicate ID, or when
a minion was rebuilt or had new keys generated and the previous key was not deleted from the master. If this
happens, delete the denied key to trigger key regeneration. In this state, connections are not accepted from
the Salt Minion and jobs are not executed.
For more on managing keys, see Keys.
4.3.3 Target settings
Targeting in SaltStack Enterprise is similar to targeting in Open Source Salt, but SaltStack Enterprise has a simplified
interface for defining targets, which also enables you to save target definitions for reuse. For more on targeting in
Salt, see .
Each target in SaltStack Enterprise includes a name, master, and target criteria, described in detail below.
Name
Enter a target name. Target names do not have to be unique. This might result in different items displaying with the
same name in the Enterprise Console.
Masters
Under the Master field, select a master whose minions you want to target. All additional target criteria are applied
only to the subset of minions associated with the selected master.
For example, if your environment has several machines responsible for running a particular application, and you
have partitioned your Salt infrastructure so these machines are all connected to a single master, you might create a
target that includes the entire subset of minions by selecting only the master.
Target criteria
Use target criteria to specify a group of minions, referring to the following field descriptions.
Targets are dynamic, and new minions are automatically added to any matching target definition. Saving your target
as a list prevents new Salt Minions that match the dynamic target setting from being added to a target automatically.

Grain Match a specific grain value, for example, osfullname is Debian. Once you select a grain, the value list
pre-populates so you can click the field to view available options, or start typing. Grains are an interface that
derives information about the underlying system. Grains are collected for the operating system, domain name,
IP address, kernel, OS type, memory, and many other system properties. For more on grains, see Salt grains
reference (https://docs.saltstack.com/en/latest/topics/grains/).
Glob Wildcard match using the minion ID. For example, you might enter webserver* to select multiple minions,
named webserver01, webserver02, and webserver03.
List Specify a list of minions to include in the target. For example, dc3-north-db1, dc3-north-db2.
Note: Specifying a list is useful if you do not want to grant access to targets dynamically. This prevents new
Salt Minions that match the dynamic target criteria from being added to a target automatically.
Compound Combine multiple target interfaces, separated by conjunctions and, or, and not. To take advantage of
compound targeting in SaltStack Enterprise, first review compound targeting in the Salt Targeting Reference
(https://docs.saltstack.com/en/latest/topics/targeting/index.html).
Note: If you select Compound as a criterion, you must follow Salt’s compound targeting syntax, and include
any secondary criteria in the compound target definition. SaltStack Enterprise does not allow you to include
any other types of criteria in addition to a Compound criterion.
4.4 See also

• Keys
• Enterprise proxy
• Pillar
4.4. See also 19


CHAPTER
FIVE
MINION KEYS
5.1 Overview
The Keys workspace is used to manage minion keys. A minion key allows encrypted communication between a Salt
Master and Salt Minion. The workspace provides an overview of all minions filtered by their respective key states.
deny.
Note: SaltStack Enterprise also provides the ability to manage master keys. For more on master keys, see Master
Plugin.
For a description of the different key states, see Key States.
5.2 How to manage minion keys
In the Keys workspace, you can accept, reject, or delete minion keys. SaltStack Enterprise also provides the ability
to manage master keys. For more on master keys, see Master Plugin.
Before accepting a new minion key, you must first install the Salt Minion service on the new machine, and configure
it to communicate with the Salt Master.
Deleting a minion key is useful for resetting a minion’s connection, for example you might delete a minion key and
then re-accept it.
For a description of the different key states, see Key States.
5.2.1 Accepting a new minion key
Note: Before you can accept a new minion key, you must first install the Salt Minion service on the new machine,
and configure it to communicate with the Salt Master. See Prerequisites to accepting keys.
1. Go to Minions > Keys > Pending.

2. Select the minion key you want to accept and click Accept Key.
3. Click Accept in the confirmation dialog.
The key is now accepted. After several seconds, the minion appears under the Accepted tab, and in the
Minions workspace.
21
Note: In a multimaster scenario, you must accept keys on all masters separately. See the Knowledge Base for
more information.
5.2.2 Rejecting minion keys
1. Go to Minions > Keys.

2. In the left panel of the workspace, select a key state to locate the required keys.
3. Select the keys you want to reject and click Reject Key.
The keys are now rejected and connections are not accepted from the Salt Minion.
Note: The key appears under the Rejected tab after several seconds.
5.2.3 Deleting minion keys
1. Go to Minions > Keys.

2. Select a key state in the left panel to locate the required keys.
3. Select the keys you want to delete and click Delete Key.
The key is now deleted.
Note: The key is removed after several seconds.
5.3 Reference
5.3.1 Prerequisites to accepting keys
Before you can accept a new minion key, you must first complete the following on the new machine:
• install the Salt Minion service
• configure the minion to communicate with the Salt Master
5.3.2 Key States
deny. SaltStack Enterprise displays keys with one of the following statuses.
Accepted Key was accepted and the minion can communicate with the Salt Master.
Pending Key is not accepted or denied. In this state, connections are not accepted from the Salt Minion and jobs
are not executed.
from the Salt Minion and jobs are not executed.
22 Chapter 5. Minion Keys

Denied Key was rejected automatically by the Salt Master. This occurs when a minion has a duplicate ID, or when
a minion was rebuilt or had new keys generated and the previous key was not deleted from the master. If this
happens, delete the denied key to trigger key regeneration. In this state, connections are not accepted from
the Salt Minion and jobs are not executed.
5.4 See also
• Minions and targets

• Enterprise Proxy
• Master Plugin
5.4. See also 23

24 Chapter 5. Minion Keys

CHAPTER
SIX
ENTERPRISE PROXY
6.1 Overview
The Enterprise Proxy is an enhanced Salt Proxy Minion that overcomes the limitations of the Proxy Minions in
Open Source Salt. In Open Source Salt, there is a one-to-one correspondence between a salt-proxy process and a
controlled device. In installations with large numbers of proxied devices, memory usage becomes a significant issue.
The Enterprise Proxy removes this limitation.
Note: For clarification on Salt Proxy Minion and Enterprise Proxy terminology, see Terminology.
The Enterprise Proxy is useful for enabling managing a large number of devices, for example, to connect to and
configure many network routers at once.
The Proxy Warden is an accompanying SaltStack Enterprise module that connects Enterprise Proxies with the avail-
able nodes as needed automatically. This eliminates the need to manually define which nodes need to run which
proxies. The Proxy Warden allows you to identify the various machines running the Salt Minion service, and dis-
tribute connections across those machines as needed to avoid overloading any one minion.
6.1.1 Difference between Proxy Minions and Enterprise Proxy
Both the Enterprise Proxy and the standard Salt Proxy Minion enable controlling devices that cannot run a standard
Salt Minion. However, the Enterprise Proxy enables control for multiple devices via a single salt-proxy process,
in contrast to the standard Salt Proxy Minion, which can control only one device per process.
This is illustrated in the following diagram.
25
In this diagram, minioncontroller1 includes two Salt Proxy Minions. Both minioncontroller2 and minioncontroller3
include an Enterprise Proxy that controls multiple Proxy Minions.
For more on the standard Salt Proxy Minion, see the Salt reference guide.
SaltStack Enterprise also includes the Proxy Warden module, which allocates Enterprise Proxies to available Minions
as needed automatically. This eliminates the need to manually define a list of Proxy Minions associated with each
Enterprise Proxy.
The Proxy Warden allows you to identify the various machines running the Salt Minion service, and distribute
connections across those machines as needed to avoid overloading any one minion.
Note: For a quick reference of Salt Proxy Minion and Enterprise Proxy terminology, see Terminology.
6.2 How to use the Enterprise Proxy
First, ensure you have configured all prerequisites. See Prerequisites. Once all prerequisites are satisfied, complete
the following steps.
26 Chapter 6. Enterprise Proxy

6.2.1 Configuring Enterprise Proxies
Like other components of Salt, the Salt Proxy Minion’s behavior is pluggable through Proxy modules. These modules
allow Proxy Minions to talk to various devices.
The Enterprise Proxy leverages the same functionality through a special Proxy module called deltaproxy.
Enterprise Proxies are best configured through Salt’s Pillar. This offers greater efficiency than editing files on every
node that will host a Control Proxy.
Note: For a quick reference of Salt Proxy Minion and Enterprise Proxy terminology, see Terminology.
1. The Pillar top file on the Salt Master should contain a reference to each Control Proxy which will be connected
to that master, as well as a reference to each Delta Proxy that will be controlled by a Control Proxy. For
example:
/srv/pillar/top.sls
base:
controlproxy1:
- controlproxy1
device1:
- device1_definition
device2:
- device2_definition
In this example, controlproxy1 is the ID for the service started with salt-proxy --proxyid
controlproxy1.
The subsequent device1 and device2 entries (along with the .sls files or pillar entries in the Enterprise
Console) contain the data necessary to communicate with the devices themselves.
2. Enter the following pillar configuration for each Control Proxy. Replace device1 and device2 with the
names of Delta Proxy IDs that will be driven by this Control Proxy.
proxy:
proxytype: deltaproxy
ids:
- device1
- device2
ids specifies the IDs of all Proxy devices to be controlled. These IDs correspond to entries in the top file
described in step 1.
3. Configure settings for each Proxy Minion in its respective sls file (or equivalent pillar entries in the Enterprise
Console), as in the following examples.
/srv/pillar/device1.sls
proxy:
proxytype: rest_endpoint_sample
host: 172.23.23.5
/srv/pillar/device2.sls
proxy:
proxytype: rest_endpoint_sample
host: 172.23.23.6
6.2. How to use the Enterprise Proxy 27

4. On each Salt Master, configure reactor settings.

Add the following reactor definition in the configuration file for the master’s connection to SaltStack Enter-
prise.
/etc/salt/master.d/raas.conf
reactor:
- 'deltaproxy/start':
- /srv/reactor/deltaproxykeys.sls
Ensure the following file exists.

/srv/reactor/deltaproxykeys.sls
Update Deltaproxy Keys:

runner.deltaproxykeys.update:
- args:
- id: {{ data['id'] }}
5. On each Control Proxy, add the following to the configuration file.

/etc/salt/proxy.
metaproxy: deltaproxy
The initial Enterprise Proxy settings are now configured.
6.2.2 Validate proxy key acceptance
This step validates that the Salt Master and Enterprise Proxy components are correctly installed. After successfully
completing the following, you can move on to configuring the Proxy Warden, which will automatically start the
Enterprise Proxy.
1. After configuring the reactor and pillar entries for the Enterprise Proxy service, on each Salt Master, restart
the salt-master process.
systemctl restart salt-master
2. On your Control Proxy, start the salt-proxy process.
salt-proxy -l debug --proxyid=<CONTROL_PROXY_ID>
Watch for error messages in the resulting console output.
3. On each Salt Master, confirm that the new key for the control proxy is visible, and accept the key. Keys for your
Delta Proxies should appear a few moments later. The Enterprise Proxy reactor accepts them automatically.
For more on accepting keys, see the Salt reference guide.
You can now run commands on the Proxy Minions as you would other Salt Minions in SaltStack Enterprise,
such as the following.
salt <PROXY_MINION_ID> test.ping
For more on minions, see Minions and Targets.
6.2.3 Configuring the Proxy Warden

Note: Before configuring the Proxy Warden, make sure to review how the Proxy Warden operates. See How the
Proxy Warden operates.
To enable the Proxy Warden:

1. After configuring the Enterprise Proxy service and accepting Proxy Minion keys, stop the Salt Proxy services.
2. On each Salt Master, remove keys for the Delta Proxies.
salt-key -d <DELTAPROXY_ID>
3. On the Enterprise server, place the following in the configuration file.
/etc/raas/raas.
proxy:
monitored: True
tgt: 'dproxy*'
tgt_type: glob
monitor_interval: 10
rebalance_interval: 20
proxies:
- ctrproxy1
In the above configuration stanza, tgt and tgt_type form a target that should match all minions that will
host Control Proxies (not proxy IDs or Delta Proxy IDs, but rather, hosts running a salt-minion that will also
run Control Proxies).
The proxies key is a list of all the IDs for control proxies. Each control proxy ID must have a pillar entry
with a proxy key, and a subkey proxymodule with a value of deltaproxy. It also needs a subkey ids
that contains a list of all the Delta Proxy IDs for which this control proxy is responsible.
Each Delta Proxy ID needs a pillar entry that starts with the proxy: key, contains a proxymodule: subkey
indicating which proxymodule needs to be loaded to communicate with this device, and also includes subkeys
for any connection information required for the device.
4. Restart the SaltStack Enterprise service.
systemctl restart raas
Within a few moments, the proxy target group and pillar appear in the Enterprise Console.
A few moments later, each minion hosting Control Proxies receives a job from SaltStack Enterprise that starts
the salt-proxy with the Control Proxy IDs.
6.2.4 Troubleshooting
• I don’t see the target group and/or pillar entries.

– Check the RaaS logs for messages from the Proxy Warden task. You might need to change the log level
to debug to see all of the messages.
• I see the target group and pillar entries for the Enterprise Proxy, but the Control Proxies never start.
– Verify that the host minions are sending the status beacon events. Log into a salt-master that has a host
minion attached, and run the following.
salt-run state.event pretty=True
Watch for Delta Proxy events in the event stream.
6.2. How to use the Enterprise Proxy 29

6.3 References
6.3.1 Prerequisites
• Install Salt Version 2019.2.1 or later on the machines that will host the Control Proxies.
Note: Salt Version 2019.2.1 or later must be installed only on these machines. This is not required for other
Salt Masters or Minions.
• Ensure that all the required libraries for talking to your devices are installed on the Control Proxy hosts. For
example, if you are talking to network devices via the Napalm libraries, ensure that all the Napalm Python
modules are installed on these machines.
• Ensure the devices you want to control are configured to communicate with the proxies. Examples of what
this might involve include:
– enabling their API endpoints
– changing firewall settings to permit network connections from the proxy machines
– configuring restricted or unrestricted user accounts on the devices
6.3.2 How the Proxy Warden operates
The Proxy Warden operates in the following manner:

1. It automatically creates a target group representing all of the Control Proxies that it sees. This target group is
defined in the SaltStack Enterprise configuration file, /etc/raas/raas.
2. It creates a pillar entry, which defines a status beacon that applies to each minion hosting one or more Control
Proxies.
3. It checks for the most recent status for these minions at a set interval defined in seconds, in the
monitor_interval key described in Configuring the Proxy Warden. If the minions appear overloaded,
the warden mark them for possible rebalancing.
4. The warden takes Control Proxies from overloaded minions and moves them to minions that are less busy. It
does this at a set interval, defined in seconds, in the rebalance_interval key described in Configuring
the Proxy Warden.
6.3.3 Terminology
SaltStack Enterprise and Open Source Salt include overlapping concepts and terminology. Refer to the following
descriptions for clarification about key terms.
Open Source Salt
Salt Proxy Minion (or salt-proxy) The single process started with the salt-proxy command that allows a de-
vice to join a Salt infrastructure.

SaltStack Enterprise
Enterprise Proxy The general term for Proxy Minions enhanced with Enterprise modules.
Control Proxy The process started by the salt-proxy command, that uses the deltaproxy proxy module,
and communicates with multiple devices.
Delta Proxy The minion ID attached to a single device, but hosted by a single Control Proxy. One Control Proxy
can support many Delta Proxies.
6.4 See also

• Targets
6.4. See also 31


CHAPTER
SEVEN
ACTIVITY
7.1 Overview
The Activity workspace is used to monitor the status of jobs and other operations. The Activity workspace has
three tabs that sort operations by status, Completed, In Progress, and Upcoming. The table on each tab shows
information about an operation, such as status, schedule (if available), target information, and more. You can adjust
the data columns displayed using the view button in the lower-left.
The Activity workspace gives visibility to many types of executions: scheduled jobs, ad-hoc jobs, and compliance
assessments. For more on assessments, see SecOps Compliance (Note: A SecOps Compliance license is required).
The Completed tab of the Activity workspace is used to monitor the status of completed operations. The Completed
tab shows the job ID (JID) for completed jobs. For more on job results, see Job results.
At the upper-right of the table you can choose a period of completed operations to show.
The In Progress tab of the Activity workspace is used to monitor the status of operations that are currently running.
It also shows minion information, the JID, and the user who started the operation.
The Upcoming tab of the Activity workspace is used to monitor the status of upcoming operations. Details about
the operation like the target, current status, start time, and associated schedule are available in the table.
At the upper-right of the table you can choose a period of upcoming operations to show.
Jobs and other operations move from In Progress to Completed when all associated nodes have finished reporting.
Note: In some cases, an operation could move to Completed with Partial status. This happens if minions fail to
respond when the master checks whether the minion is still working on an assigned task. In these cases, SaltStack
Enterprise checks with the master to see if the operation is running. If the master reports that the operation has
finished running, the operation moves to the Completed tab, but displays with Partial status.
Minions might not return anything due to system misconfiguration, network outages, client issues, or machine
failures. In these cases, the job might show with Partial status under the Completed tab.
7.2 How to use the Activity workspace
You can pause or stop operations that are in progress, or skip upcoming iterations of a scheduled operation. You can
also adjust the table view to show or hide additional details.
33
7.2.1 Pausing an operation
1. Go to Activity > In Progress, and select the operations you want to pause.
2. Click Pause.
3. Click Pause in the confirmation dialog.
Note: Depending on operation size and progress, the operation may finish running before it can be paused.
7.2.2 Stopping an operation
1. In the In Progress tab, select the operations you want to stop.

2. Click Stop.
3. Click Stop in the confirmation dialog.
Note: Depending on operation size and progress, the operation may finish running before it can be stopped.
7.2.3 Skipping an operation
1. In the Upcoming tab, select the operations you want to skip.

2. Click Skip.
3. Click Skip in the confirmation dialog.
7.2.4 Filtering by time range
1. In either Completed or Upcoming, go to the upper-right of the Activity workspace and click the dropdown.
2. In the resulting menu, select the time range of activity you want to see, for example Past 12 Hours or Next 12
Hours.
34 Chapter 7. Activity
7.2.5 Changing table columns
1. In any tab of the Activity center, click the Column button in the lower left corner.
2. In the menu, select or deselect columns you want to include in the table view.
7.2. How to use the Activity workspace 35

7.3 Reference
7.3.1 Statuses
Each tab in the Activity workspace includes additional status details for each operation as follows.
In Progress
Running Operation is currently running.

Paused Operation began running but was paused by a user. You can resume the operation as needed.
Pausing Operation is looking for an opportunity to pause, between executing different tasks.
Resuming Operation is attempting to continue running.
Queued Operation is attempting to start running.
Stopping Operation is looking for an opportunity to stop, between executing different tasks.
Upcoming
Scheduled Operation will run at a set time, indicated in the Start time column.
Skipping Operation instance scheduled for the indicated time will not run.
Disabled Operation is part of a disabled schedule, and will not run.
Note: For more on schedules, see Schedules.
Completed
Completed Operation has finished running.

Partial Operation is still waiting for some minions to return, though the master has reported that the operation has
finished running.
Skipped Operation was scheduled for the indicated time but did not run.
Disabled Operation is part of a disabled schedule; it was scheduled for the indicated time but did not run.
Stopped Operation was stopped and cannot be resumed.
Failed Operation ran but failed on one or more minions.
7.4 See also
• Jobs
• Job Results
• Schedules
36 Chapter 7. Activity
CHAPTER
EIGHT
JOBS
8.1 Overview
Jobs are used to run remote execution tasks, apply states, and start Salt runners. The Jobs workspace is where you
can configure and save job settings for reuse. You can run jobs from within the Jobs workspace, or from other screens
in Enterprise Console.
Each job in the Jobs workspace has predefined settings. You can edit settings on existing jobs, or create a new job
with its own unique settings.
In order for a job to run, it must include both a function and either a target, a master, or multiple masters. You can
define a target in a job’s settings, or leave the target undefined to select a target each time the job runs.
The Jobs workspace allows you to define role-based access to each job. In addition to defining role access on the
job, you must also assign roles permission to execute corresponding tasks in the Roles editor. For more on job
permissions, see Roles and permissions.
8.2 How to use Jobs
You can create new jobs and edit existing ones from the Jobs workspace. Once job settings are defined, you can run
ad-hoc jobs, or create schedules to run jobs in the future. See Schedules.
SaltStack Enterprise includes a Run Command control that allows you to run a single command without defining
a reusable job. This is useful for executing commands quickly, or running one-off jobs that are not part of your
everyday workflow, for example when troubleshooting, or during initial configuration. For more information, see
Running a command.
You can also define which roles can view, edit, run, and delete different jobs.
8.2.1 Opening the jobs workspace
1. In the navigation bar, select Elements and go to Jobs.
8.2.2 Creating a job
1. In the Jobs workspace, click Create job.

2. Enter details for the new job. The details to enter depend on the type of job you want to create. See Reference.
3. Click Save. The job is now available to run.
37
8.2.3 Running a job
1. In the Jobs workspace, click the menu for the job you want to run.
2. Click Run Now.
3. In the popup, select a target to run the job on.
Note: If the job is configured to include a target or master, this is displayed for confirmation.
4. Select additional options as required.

• Set notification preferences
• Select Run as Test (dry run) to run job as a test as required.
5. Click Run Now.
Note: You can also run jobs from the Minions workspace. See Minions and Targets.
8.2.4 Viewing job returns
1. In the navigation bar, select Activity and go to Completed to see a list of completed jobs.
2. Select a job ID in the JID column to view the job return details. For more on job returns, see Job Returns.
8.2.5 Editing a job
1. In the Jobs workspace, select a job.

2. Edit job details as needed and click Save when finished.
38 Chapter 8. Jobs
8.2.6 Defining job permissions
1. In the Jobs workspace, select a job.

2. In the job details page, click Role Access.
3. In the dialog, select the level of access to enable for different roles and click Save.
4. In the job details page, click Save.
Note: In addition to defining role access on the job, you must also assign roles permission to execute corre-
sponding tasks in the Roles editor. For more on job permissions, see Roles and permissions.
8.3 Reference
Define job settings based on the following options.
8.3.1 Name
Enter a name for the job. This will show in the Jobs, Minions, and Activities workspaces, as well as in the Roles
editor.
8.3.2 Description
Enter a description for the job (optional). This description will show in your list of jobs in the Jobs workspace.
8.3.3 Command
Specify the command to run, choosing from:

• salt - define a job to run on a target group of minions. See Target.
• salt-run - define a job to run on a Salt Master or group of masters. See Master.
Note: SaltStack Enterprise includes a Run Command control that allows you to run a single command without
defining a reusable job. This is useful for executing commands quickly, or running one-off jobs that are not part of
your everyday workflow, for example when troubleshooting, or during initial configuration. For more information,
see Running a command.
Target
A target is the group of minions, masters, or a single master that a job’s Salt command applies to. When salt is
selected, you can optionally specify the target group of minions to run the job on. If the field is left blank, you will
be prompted to select a target each time the job runs.
8.3. Reference 39
Master
The Salt Master is a central node used to issue commands to minions. When salt-run is selected, specify a Salt
master to run the job on, or use the default All Masters setting.
salt-run jobs are also known as Salt runners. Salt runners are modules used to execute convenience functions
on the master. For more on using salt-run, see Salt runners.
8.3.4 Function
Enter a function to define what happens when the job runs. You can define a single remote execution job, a state file
job, or a Salt runner job. For a list of Salt functions, see Salt Module Reference (https://docs.saltstack.com/en/latest/
ref/index.html).
Single remote execution jobs
To define a single remote execution job, include a function and any necessary arguments in the job settings.
40 Chapter 8. Jobs
State file jobs
A state file job applies states to a target, and can be based on at least one command. A state function is a function
contained inside a state module which can manage the application of a particular state to a system. State functions
frequently call out to one or more execution modules to perform a given task. A highstate applies all states defined
in the top file. You can view and add state files in the File Server. See File Server.
To apply a state file to a job, use the state.apply function. To perform a highstate, use the state.apply or
state.highstate function in the job settings.
When you add a state call to a job, additional fields display where you can select the state files you want to apply.
You can also pass optional pillar overrides in JSON format.
Note: Pillar data provided on the job page is sent along with the job and other authenticated minions might be able
to see it. For increased data protection, assign sensitive data in standard pillar instead. See Pillar.
For more on Salt States, see the Salt documentation: How do I use Salt States? (https://docs.saltstack.com/en/latest/
topics/tutorials/starting_states.html).
Salt runners
A salt-run job applies to a master or group of masters. salt-run jobs are also known as Salt runners. Salt
runners are modules used to execute convenience functions on the master. You can use Salt runners to run orches-
tration, power minions remotely, call webhooks, and more. They are useful for executing tasks centrally or from a
central starting point, for example to apply a highstate to all minions associated with a given master.
To configure an orchestration runner job, use the state.orchestrate function. When you add an orchestration
call to a job, additional fields display where you can list the orchestration files you want to apply. You can also pass
optional pillar overrides in JSON format.
Note: Pillar data provided on the job page is sent along with the job and other authenticated minions might be able
to see it. For increased data protection, assign sensitive data in standard pillar instead. See Pillar.
For more on Salt runners, see the Salt Runners Reference (https://docs.saltstack.com/en/latest/ref/runners/).
8.3. Reference 41
8.3.5 Environments
Select the environment where the state or orchestration file is located. This is a subdirectory of the root directory in
the File Server. File Server.
8.3.6 Test (dry run)
Run a test job and generate a mock job return. If you select Test, the job will not run and no changes will be made.
If this option is left unselected, you can choose to run the job as a test later when you run the job.
Test (dry run) is available only for certain functions. For more information, contact your administrator.
8.4 See also

• Targets
• Pillar
• File Server
• Job Results
42 Chapter 8. Jobs
CHAPTER
NINE
JOB RETURNS
9.1 Overview
Job returns provide details about results of jobs that have finished running. SaltStack Enterprise includes several
custom outputters to format results for common job types.
Jobs are used to run remote execution tasks, apply states, and start Salt runners. For more on jobs, see Jobs.
9.2 How to view job results
You can view a list of completed jobs for a given minion, or from a given time period. You can also view a detailed
report of each job return. For more on custom outputters included in job returns, see Custom Outputters.
Minions are nodes running the Salt Minion service, which can listen to commands from a master and perform the
requested tasks. For more on minions, see Minions and Targets.
9.2.1 Viewing job results by minion
1. Go to the Minions workspace and select a minion ID.

2. In the Details page, select the Activity tab.
The Activity tab shows a list of up to the last 500 jobs run against the selected minion in Enterprise Console.
3. Select the JID of the job return you want to view.
Note: SaltStack Enterprise returns data through Salt Masters and then to the Enterprise API returner, so the job
history tab might not show data immediately. If you are viewing job results for a single job run immediately after
starting the job, the results tab might show incomplete data until the Salt Masters have processed the returns and
pushed them back to the Enterprise API.
9.2.2 Viewing job results by time of completion
1. Go to Activity > Completed.

The Completed tab shows a list of completed jobs. You can select the dropdown in the upper right to select
a different time period to view results from.
For more on the Activity workspace, see Activity.
43
2. Select the JID of the job return you want to view.
9.2.3 Downloading job results
1. Select a JID, following steps to view job results by minion or time of completion above.
2. Click JSON in the upper right of the job return.
The .json file starts downloading to your browser.
9.3 Reference
9.3.1 Job return information fields
The job results page displays the following details about the selected job run:
function | job id (jid) Displays general information about the job.
job name | target | masters | user | return details Displays specific information about this job run.
Summary | Custom outputter | Default | Full | Raw | Job Info Change the return data formatting by selecting
from the following options.
Summary A list of minions targeted by the job. Each minion includes additional details you can view by
opening or closing its respective dropdown.
Custom outputter A customized representation of the job results designed for the function associated with
the job. If a custom outputter is available, it is automatically selected by default. For more on custom
outputters, see Custom Outputters.
Default A minimal set of job return data in an expandable list.
Full All job returns by minion in an expandable list.
Raw Raw JSON data structure with minimal formatting.
Job info High-level job overview, including minions expected to return as well as those that did not return.
Minion ID filter Quickly display results for a subset of Salt Minions.
Success | Failed | Test Expand or shrink job results by return type. By default, Failed is selected to display addi-
tional data for Salt Minions that reported a failure. Test expands locations where test=True indicates that
changes would be made.
9.3.2 Custom Outputters
SaltStack Enterprise includes several custom outputters to format results for common job types, incuding the fol-
lowing:
• State jobs
• test.ping
• disk.usage
• user.getent
• status.cpuinfo
• network.routes
44 Chapter 9. Job Returns

• network.ipaddrs
• network.netstat
• cmd.run
• cmd.script
• pkg.list_pkgs
Examples
This section includes examples of a selection of custom job return outputters.
State Jobs
Returns results of a given state module when running a state job, including state.sls, state.highstate,
state.apply. A state function is a function contained inside a state module which can manage the application
of a particular state to a system. State functions frequently call out to one or more execution modules to perform a
given task. For more on Salt States, see . For more on jobs, see Jobs.
Test.ping
Returns results of running test.ping for each node in the target group.
Disk Usage
Returns usage information for volumes mounted on minions in the target group.
9.3. Reference 45
Getent
Returns information for OS-defined user groups on the targeted minions.
CPU info
This outputter includes different views you can apply using the left column.
Routes
Returns currently configured routes from routing table.

IP Address
Returns a list of IPv4 addresses assigned to the host.
Netstat
An interactive graph displays connections between minions and masters.
List packages
Displays packages currently installed on each minion.
9.4 See also
• Jobs
• Minions and Targets
9.4. See also 47


CHAPTER
TEN
SCHEDULES
10.1 Overview
Schedules are used to automate job execution. You can schedule one-off or recurring jobs to monitor your environ-
ment and run jobs continuously at any time. In the Schedules workspace, you can disable schedules and skip jobs,
as well as run a scheduled job.
SaltStack Enterprise includes a range of scheduling options, allowing you to build custom schedules based on your
organization’s needs. Scheduling is also available through the SaltStack Enterprise Scheduler API. See RPC Schedule
Interface.
You can access your scheduled jobs, sorted by status, in the Activities workspace. See Activities. For more on how
to define job settings, see Jobs.
10.2 How to use Schedules
You can create schedules to run jobs at set intervals over a defined time period. The Schedules workspace also has
controls you can use to run or skip a job or disable an entire schedule.
10.2.1 Creating a schedule
1. In the navigation bar, select Elements and go to Schedules.

2. In the Schedules workspace, click Create Schedule.
3. Enter a schedule name and define custom settings. See Schedule settings.
4. Click Save.
10.2.2 Checking job status
1. In the Schedules workspace, click on a schedule name.

2. You can select the different status tabs to view upcoming, completed, and in-progress jobs associated with the
schedule. For more about the different statuses, see References_.
Note: You can also view the status of scheduled jobs in the Activities workspace. See Activities.
49
10.2.3 Modifying a schedule
1. In the Schedules workspace, click on a schedule name.

2. Click Edit Schedule.
3. Modify the schedule settings as needed. See Schedule settings.
4. Click Save.
Running a scheduled job
1. In the Schedules workspace, select the checkbox associated with the scheduled job.
Note: You can select more than one schedule to run multiple jobs at once.
2. Click Run now.

3. In the confirmation popup, click Run now.
Skipping a scheduled job instance
1. In the Schedules workspace, click on a schedule name and go to the Upcoming tab.
2. Select the checkbox associated with the job instance you want to skip.
3. Click Skip.
4. In the confirmation dialog, click Skip.
Disabling an entire schedule
1. In the Schedules workspace, select the checkbox associated with the schedule.
2. Click Disable.
3. In the confirmation dialog, click Disable.
10.3 Reference
10.3.1 Schedule settings
Define schedule settings based on the following.
Job / Command
Specify the job or command to include in the schedule. For more on defining job settings, see Jobs.
Target
A target is the group of minions, masters, or a single master that the job’s Salt command applies to. This field allows
you to choose either a target group or master, depending on the selected command.
50 Chapter 10. Schedules

Timezone
Jobs included in the schedule run based on the time zone indicated in this field.
Schedule frequency
Choose the schedule frequency from Recurring, Repeat Date & Time, Once, or Cron Expression. Additional
options are available, depending on the scheduled activity, and on the schedule frequency you choose.
Recurring Set an interval for repeating the schedule, with optional fields for start or end date, splay, and maximum
number of parallel jobs.
Repeat Date & Time Choose to repeat the schedule weekly or daily, with optional fields for start or end date, and
maximum number of parallel jobs.
Once Specify a date and time to run the job.
Cron Enter a cron expression to define a custom schedule based on Croniter syntax. See the CronTab editor (https:
//crontab.guru/examples.html) for syntax guidelines. For best results, avoid scheduling jobs fewer than 60
seconds apart when defining a custom cron expression.
10.3.2 Statuses
The Schedules workspace displays the current status for each schedule. When you view details for a schedule, you
can also see the current status for each scheduled job.
Schedule
Schedules can be either enabled or disabled.

Enabled All jobs will continue to run according to schedule settings without interruption.
Disabled All jobs included in the schedule are disabled and will not run.
Scheduled jobs
Schedules can include upcoming, completed, and in-progress jobs. See Activity.
10.4 See also
• Jobs
• Activity
• RPC Schedule Interface
• Job Results
10.4. See also 51

52 Chapter 10. Schedules

CHAPTER
ELEVEN
DIRECTORY SERVICE
11.1 Overview
The Directory Service workspace is used to connect SaltStack Enterprise to an Active Directory (AD) or other
Lightweight Directory Access Protocol (LDAP) server. This allows users and groups defined by your LDAP server
to be used to authenticate to SaltStack Enterprise. It also allows you to define Role Based Access Controls for these
users and groups inside SaltStack Enterprise.
Settings for users defined through LDAP are managed differently from local users settings. For best results, once
LDAP is enabled, use LDAP as your primary method for creating and managing users. See Users.
Once you have defined your users, you can also define permissions using SaltStack Enterprise’s Role Based Access
Control (RBAC). See Roles and Permissions.
Note: References to LDAP in this article include both traditional LDAP and Active Directory-based LDAP.
11.2 How to use Directory Service
To use Directory Service, first create a connection, then enable specific users and groups to authenticate with Salt-
Stack Enterprise. Once you have enabled groups or users, you can define their Role-Based Access Control (RBAC)
settings.
You can edit or update your Directory Service, as well as delete a connection as needed.
Note: The following steps should be completed by an experienced LDAP or Active Directory administrator who
understands the overall LDAP system layout.
11.2.1 Creating a Directory Service connection
1. Go to Menu > System Administration > Directory Service.

2. Click Create.
3. Under Settings, enter details for your directory service. See Directory Service information fields.
Note: To set up your connection more quickly, click Prefill Defaults, then select your service from the
dropdown.
53
The default entries populate according to your selection. However, certain entries such as User Search DN are
incomplete. Make sure to verify entries match your directory service schema.
4. To preview your settings without saving, click Update Preview.

The preview window shows users and groups selected for your connection. You can select either tab to preview
users and groups associated with the service as needed.
5. Click Save.
SaltStack Enterprise stores the connection settings, including the groups and users identified. It retrieves only
groups and users within the scope you have defined and does not synchronize the entire directory. For more
on how this works, see Authentication process.
You can now enable specific groups and users to authenticate with SaltStack Enterprise.
11.2.2 Enabling groups
1. In the Directory Service workspace, select the required Directory Service connection.
2. Select the Groups tab to see a list of groups retrieved from your directory service.
Note: If you’re retrieving a large number of groups, the page might take up to a minute to load.
3. Select the groups you want to enable in SaltStack Enterprise.

4. Click Save.
You can now define Role-Based Access Control (RBAC) settings for the selected groups. However, the Roles
workspace allows you to manage settings for individual users included in the selected groups only after the
user’s first login. For more information, see Login.
For more on RBAC in SaltStack Enterprise, see Roles and Permissions.
11.2.3 Enabling users
2. Select the Users tab to see a list of users retrieved from your directory service.
Note: If you’re retrieving a large number of users, the page might take up to a minute to load.
3. Select the users you want to enable in SaltStack Enterprise.
Note: Any users included in enabled groups are already selected and can’t be deselected.
54 Chapter 11. Directory Service

4. Click Save.
You can define Role-Based Access Control (RBAC) settings for the selected users after the user’s first login.
For more information, see Login.
For more on RBAC in SaltStack Enterprise, see Roles and Permissions.
11.2.4 Removing groups
2. Select the Groups tab to see a list of groups included in the connection. Enabled groups are selected.
3. Deselect groups you want to remove from SaltStack Enterprise and click Save.
Users included in the group can no longer log in to SaltStack Enterprise.
Note: Any groups you remove from your Directory Service connection are archived. Even though they’re
inactive and users can’t log in, they’re still visible in the Roles workspace. For more information, see Archived
groups and users.
For more on managing roles, see Roles and Permissions.
11.2.5 Removing users
2. Select the Users tab to see a list of users included in the connection. Enabled users are selected.
3. Deselect users you want to remove from SaltStack Enterprise and click Save.
Note: You can’t deselect individual members of an enabled group. For more information, see Enabling users.
Any users you remove from your Directory Service connection are archived. Even though they’re inactive
and can’t log in, they’re still visible in the Roles workspace if the user has previously logged in.
For more information, see Archived groups and users.
11.2.6 Editing Directory Service connection settings
Note: If you want to pull in updates your directory service without modifying your settings, see Updating your
Directory Service.
1. In the Directory Service workspace, select the Directory Service connection you want to edit.
2. Edit the fields for your Directory Service connection as necessary. See Directory Service information fields.
3. Under Admin Bind password, click Change Password and re-enter your password.
4. Click Save.
11.2. How to use Directory Service 55

Updating your Directory Service
1. In the Directory Service workspace, select the Directory Service connection you want to update, for example
if you have added new users and want to enable them in SaltStack Enterprise.
2. In the Settings tab, click Update Preview.
The preview updates to reflect the latest users and groups retrieved from your service.
3. Click Save.
11.2.7 Deleting a Directory Service connection
1. In the Directory Service workspace, select the Directory Service connection you want to delete.
2. Click Delete.
3. In the confirmation dialog, click Delete.

The Directory Service Connection is now deleted, along with all associated users and groups. Jobs and other
items created by deleted users remain in SaltStack Enterprise and root is the item owner.
11.3 Reference
11.3.1 Directory Service information fields
Enter information for your Directory Service connection as follows.
Note: If you need assistance setting up your connection, contact your administrator.

Basic
Field Description
Name Name of Directory Service connection.
Host LDAP host server address, formatted as either a FQDN or IP address.
Port Port where LDAP server is configured. The default is 389 for unencrypted LDAP,
and 636 for LDAP over SSL.
Background Sync SaltStack Enterprise validates all users and group against the authentication backend
at a set interval defined (in minutes) here.
SSL
Enable SSL Select to connect to the LDAP server over a Secure Sockets Layer (SSL)
using the certificate specified in your SaltStack Enterprise server settings. If no
configuration is provided, the system certificates store will be used to validate
the SSL connection. For more on setting up the SaltStack Enterprise server,
see https://enterprise.saltstack.com/sse.
Note: As a best practice, select Use SSL. When this option is left unselected,
SaltStack Enterprise transmits information in plain text over an insecure con-
nection.
Validate Certificate Select to ensure the SSL certificates are validated upon con-
necting. Leave unselected to skip validation, for example when using self-
signed certificates (not recommended for production).
11.3. Reference 57
Authentication
Field Description
Auth Base DN Base LDAP Distinguished Name. This is the location groups and users are queried
from, for example DC=example,DC=com.
Note: The LDAP details page includes separate input fields for Person Object Class,
Account Attribute Name, Group Class, Group Attribute Name, and Sync Scheduling, as
described below. Therefore, do not include these objects in the Base DN field.
Admin Bind DN Administrator DN configured for the LDAP server. SaltStack Enterprise uses this to
authenticate to the directory for user and group lookups. Enter input based on the
following syntax: cn=Administrator,cn=Users,dc=example,dc=com.
Admin Bind DN Password The password provided when logging in as an administrator.
Auth Bind DN Filter Filter applied to select a specific user. The result of this search is a user DN that Salt-
Stack Enterprise uses to bind to the directory and grant the user access to SaltStack
Enterprise.
The following sample filter would return only an account matching the provided
username belonging to the DevOps or Level II groups.
(&(objectclass=user)(sAMAccountName={username})
(|(memberOf=CN=DevOps,OU=Groups,OU=Test Company HQ,DC=adtest,
˓→DC=com)
(memberOf=Level II,OU=Groups,DC=adtest,DC=com)))
Note: When configuring a forest structure, leave this field blank.

Groups
Field Description
Group Search DN The search base for groups, for example, cn=Groups,dc=example,dc=com.
Indicates where in the directory to search for groups. Use along with Group Search
Scope below.
Group Search Scope Indicates directory search depth from the base indicated in Group Search DN and
can have one of four values:
baseObject Value 0, often referred to as base. Use this to search only for this
object and no other.
singleLevel Value 1, often referred to as one. Use this to consider only imme-
diate children of the base entry for matches.
wholeSubtree Value 2 (or SUBTREE in ldap3), often referred to as sub. Use this
to search to base and all of its subordinates to any depth.
subordinateSubtree Value 3, often referred to as subordinates. This is
the same as wholeSubtree but the base search entry is ignored.
Group Search DN Filter Search filter for extracting groups from the directory. This is typically
(objectClass=group), but in some AD configurations it might be
(objectCategory=group). Use in addition to Group Class for more
granularity.
Group Class Object class name used to define groups, for example groupOfNames.
Group Member Attribute The name of the attribute in the user entry that contains the group name, for example,
memberOf.
Group Membership Select if your directory stores group memberships as Distinguished Names.
Users
Field Description
User Search DN The search base for users, for example, cn=Users,dc=example,dc=com in AD
or cn=people,cn=accounts,dc=example,dc=com in other directory ser-
vices. Indicates where in the directory to search for users. Use along with User
Search Scope below.
User Search Scope Indicates directory search depth from the base indicated in User Search DN and can
have one of four values. See the four values described in Group Search Scope.
User Search DN Filter Search filter for extracting users from the directory. This is typically
(objectClass=person) but in some AD configurations it might be
(objectCategory=user).
Person Class Directory Service class name containing users you want to enable to log in. Most
systems (including Active Directory) use person, but some may prefer user or
inetOrgPerson.
User ID Attribute The unique name of the user account attribute. For AD this is sAMAccountName.
For other services it is often uid or memberUid.
11.3.2 Authentication process
Preview
When you preview your connection settings, SaltStack Enterprise retrieves a sample list of users and groups from
your LDAP server so you can verify you have entered the correct configuration parameters.
11.3. Reference 59
Login
When a user enters credentials in the SaltStack Enterprise login form, the backend server checks for a match in the
database at that time. It then initiates a multi-step lookup process and, upon finding a match, authenticates the user.
Given this lookup process, enabled individual users in enabled groups do not appear in the Roles workspace until
the user’s first login.
Background tasks
SaltStack Enterprise runs a background job periodically to look up each linked group and user in the Directory
Service connection to ensure it still exists. If the group or user has been removed, the backend server deactivates its
link in the database.
11.3.3 Archived groups and users
Any groups you remove from your Directory Service connection are archived. Even though these groups are inactive
and users can’t log in, they’re still visible in the Roles workspace and can be selected. This also applies to any removed
users previously visible in the Roles workspace.
11.3.4 Nested groups
When working with nested groups, the Directory Service workspace does not accurately reflect when a nested (or
child) group is enabled. By enabling a parent group, you also enable all child groups by default. However, in the
workspace, the child groups do not appear to be enabled.
11.4 See also

• Users

CHAPTER
TWELVE
LOCAL USERS
12.1 Overview
Local users are users whose username and password are stored in the database. You can manage local user settings,
such as user passwords, in Enterprise Console. In contrast, settings for users synchronized from a Directory Service
connection are managed through your Lightweight Directory Access Protocol (LDAP) or Active Directory server.
For more on Directory Service, see Directory Service.
Whether a user is local, or synchronized from a Directory Service connection, you can manage the user’s roles and
permissions within Enterprise Console using SaltStack Enterprise’s Role Based Access Control (RBAC). See Roles
and Permissions.
By default, a local user is associated with each Salt Master key used for authentication. For more on master keys,
see Master Plugin.
12.2 How to manage local users
In the Local Users workspace, you can create or clone local users. You can also update user settings, for example
to change user passwords.
12.2.1 Creating a Local User
1. Go to Menu > System Administration > Local Users and click Create.
2. Enter a username and password, and select any roles you want to add the user to.
All new users are added to the User role by default. For more on roles, see Roles.
3. Click Save.
Note: Only superusers, or users with Create user permission, are able to create local users. Usernames are not
case-sensitive.
12.2.2 Cloning a Local User
1. Under System Administration > Local Users, select the user you want to clone and click Clone.
2. Enter a username and password, and select any roles you want to add the user to.
61
3. Click Save.
12.2.3 Changing user settings
1. Under System Administration > Local Users, select the user you want to update.
2. With the user selected, change user settings as required. You can update the username, password, and assigned
roles.
3. Click Save.
12.2.4 Changing root password
• Change the root password in the Enterprise Console using the instructions above.
12.3 Reference
12.3.1 Roles
Roles in SaltStack Enterprise give you the ability to create specific management roles, and then add the appropriate
users to those roles. Roles control which Salt minions each user can view and which operations a user can perform
in Enterprise Console. See Roles and permissions.
12.3.2 Master key authentication
By default, a local user is associated with each Salt Master key used for authentication. For more on master keys,
see Master Plugin.
12.4 See also

• Enterprise Installation Guide (https://enterprise.saltstack.com/)
62 Chapter 12. Local Users

CHAPTER
THIRTEEN
ROLES AND PERMISSIONS
13.1 Overview
The Roles workspace is used to manage permissions. With SaltStack Enterprise’s Role Based Access Control (RBAC),
you can define permission settings for multiple users at once, as permission settings for a role apply to all users
included in the role.
Role permissions are additive. Users assigned to multiple roles receive access to a combination of all items granted
from each role. This helps ensure users with similar backgrounds receive the same permission settings, and users
with a range of responsibilities have access to everything they need.
SaltStack Enterprise ships with a number of built-in roles that cannot be deleted. Additionally, you can create custom-
defined roles for your organization’s unique needs. See Types of roles.
To give a role permission to complete a task, you must both define the permitted task, and also assign access to a
resource or functional area. A permission is a broad category of allowed actions, whereas resource access allows
you to define a specific resource (for example, a job or target) the action can be completed against. See Difference
between permitted tasks and resource access.
13.2 How to use the Roles workspace
The Roles workspace offers tools to add users to a role, as well as define permissions and resource access for different
roles. It also includes an advanced editor, recommended for advanced SaltStack Enterprise users only. For more on
the advanced editor, see Advanced roles editor.
In some cases, cloning a role might be more convenient than creating a new one. You can clone an existing role, and
then modify the clone as needed.
Note: Role permissions are additive. Users assigned to multiple roles receive access to a combination of all items
granted from each role.
Resource access for certain resource types and functional areas must be defined in the Enterprise API, rather than
the Roles editor. See Resource access.
13.2.1 Creating a role
1. Go to Menu > System Administration > Roles.

2. Click Create.
63
3. Enter a new name for your role.

4. Under Tasks, select permitted actions to grant the role. For a description of the available tasks, see Tasks.
5. Click Save.
You have completed the minimum steps necessary to create a role. For more on defining the role’s settings,
see Editing a role.
13.2.2 Cloning a role
1. In the Roles workspace, select the role you want to clone.
Note: For security reasons, the built-in Superuser role cannot be cloned.
2. Click Clone.
3. Enter a new name for your role, and then click Save.
You have completed the minimum steps necessary to clone a role. For more on defining the role’s settings, see
Editing a role.
Note: Cloned roles inherit permitted tasks from the original role by default. Cloned roles do not inherit
resource access, which must be defined separately. See Assigning access to a job or target.
13.2.3 Editing a role
1. In the Roles workspace, select the role you want to edit.

2. Select any tab (from Tasks, Resource Access, Groups, or Users) and edit role settings as needed.
For more on editing each tab, see below.
3. Click Save after making changes, before selecting a new tab.
Note: The above describes how to edit a role using the standard editor. SaltStack Enterprise also includes an
advanced editor recommended for advanced users only. For more on the advanced editor, see Advanced roles editor.
Setting permitted tasks

2. Under Tasks, select permitted tasks to assign the role. Tasks represent common use cases in SaltStack Enter-
prise. Enabling a task gives the role all permissions required to complete the task.
For task descriptions, see Tasks.
3. Click Save.
Note: In addition to assigning a permission, you must enable access to the specific resources (such as a job or target)
for the role to perform the action on. See Difference between permitted tasks and resource access.
64 Chapter 13. Roles and Permissions

Assigning access to a job or target

2. Under Resource Access, locate the required job or target, and select the access level you want to provide. For
example, to allow a role to run jobs, you would select Read/Run for the job.
If the resource you want to select is not displaying, click Show all Targets or Show all Jobs, respectively.
In SaltStack Enterprise, both jobs and targets are considered different types of resources. For more on resource
access, see Resource Access.
3. Click Save.
Note: In addition to assigning resource access for a job, you must also assign access to a target for the job to run
on, and assign permission to run jobs. See Difference between permitted tasks and resource access.
Adding or removing groups

2. Under Groups, select the groups you want to include in the role.
Groups are imported through a directory service connection. If you don’t see the group you were expecting,
ensure you have added the connection and synchronized groups.
Any groups you remove from your Directory Service connection are archived. Even though they’re inactive
and users can’t log in, they’re still visible in the Roles workspace.
For more on Directory Service, see Directory Service.
Note: Role permissions are additive. Users in groups assigned to multiple roles receive access to a combination
of all items granted from each role.
3. Click Save.
The selected groups, including all users in those groups, are now granted all permitted tasks and resource
access defined in the role settings.
13.2. How to use the Roles workspace 65

Adding or removing users
Note: Users inherit permission settings (such as being assigned to a role) from the groups they belong to. A best
practice is to avoid adding individual users to a role, but rather add the user to a group that belongs to the role. All
new users are included in the User role by default. See Built-in roles.

2. Under Users, select the users you want to include in the role.
The Roles workspace allows you to manage settings for individual users included in a Directory Service group
only after the user’s first login. For more information, see Directory Service.
3. Click Save.
13.3 Reference
To give a role permission to complete a task, you must both define the permitted task, and also assign resource access.
Both are described in further detail below.
13.3.1 Tasks
Tasks represent common use cases in SaltStack Enterprise. Enabling a task gives the role all permissions required to
complete the task.
The Tasks tab includes the following options.

Task Description
Create and delete new tar- Role can create new targets. Users assigned to this role can edit and delete targets
gets they have created, or other targets defined under Resource Access.
A target is the group of minions, masters, or a single master that a job’s Salt command
applies to. For more on targets, see Minions and targets.
Modify pillar data Role can view, edit, and delete sensitive information stored in pillars. Users belong-
ing to the role can edit or delete pillars they have created. They can also edit or delete
other pillars if granted resource access (available through Enterprise API only).
Pillars are structures of data defined on the Salt Master and passed through to one
or more minions, using targets. They allow confidential, targeted data to be securely
sent only to the relevant minion. For more on pillar, see Pillar.
Modify filesystem Role can view the file server, and can create, edit, or delete files. Users belonging to
the role can edit or delete files they have created. They can also edit or delete other
files if granted resource access (available through Enterprise API only).
The file server is a location for storing both Salt-specific files, such as top files or state
files, as well as files that can be distributed to minions, such as system configuration
files. For more on the file server, see File server.
Run arbitrary commands Role can trigger commands outside of a job for the Salt Master to pick up. Role is
on minions not limited to running only commands included in a given job’s definition.
Minions are nodes running the Salt Minion service, which can listen to commands
from a master and perform the requested tasks. For more on minions, see Minions
and targets.
Accept, delete, and reject Role can accept, delete, and reject minion keys as needed for initial configuration.
keys A minion key allows encrypted communication between a Salt Master and Salt Min-
ion. For more on keys, see Keys.
Read and modify users, Role can view users and associated data, as well as edit roles and permissions set-
roles, permissions tings.
Note: This task applies only to the built-in Administrator and Superuser roles.
Roles are used to define permissions for multiple users who share a common set of
needs.
Run commands on Salt Role can run commands on Salt Masters, for example to run orchestration.
Masters Commands run against the master are also called Salt runners. Salt runners are
modules used to execute convenience functions on the master. For more on runners,
see Jobs.
Compliance - create, edit, Role can create, edit, delete, and assess SecOps Compliance Compliance policies. In
delete, and assess addition to granting permission for this task, you must also define resource access
for any targets you want the role to perform actions on. For example, if you want
the Oracle Linux Admin role to define policies for an Oracle Linux target,
you would assign the role both permission to complete this task, and Read access to
the Oracle Linux target.
This task does not allow the role to remediate SecOps Compliance Compliance poli-
cies.
SecOps Compliance is an add-on to SaltStack Enterprise that manages the security
compliance posture for all the systems in your environment. For more on Sec-
Ops Compliance, see SecOps Compliance. Note: A SecOps Compliance license is
required.
Compliance - remediate Role can remediate any non-compliant minions detected in a SecOps Compliance
Compliance assessment.
SecOps Compliance is an add-on to SaltStack Enterprise that manages the security
compliance posture for all the systems in your environment. For more on Sec-
Ops Compliance, see SecOps Compliance. Note: A SecOps Compliance license is
required.
Compliance - update Salt- Role can download updates to the SecOps Compliance Compliance security library.
Stack content
13.3. Reference 67
Task Description
Vulnerability - create, Role can create, edit, delete, and assess SecOps Vulnerability policies. In addition
edit, delete, and assess to granting permission for this task, you must also define resource access for any
targets you want the role to run assessments against.
This task does not allow the role to remediate SecOps Vulnerability policies.
SecOps Vulnerability is an add-on to SaltStack Enterprise that manages vulnerabili-
ties on all the systems in your environment. For more on SecOps Vulnerability, see
SecOps Vulnerability. Note: A SecOps Vulnerability license is required.
Vulnerability - remediate Role can remediate vulnerabilities detected in a SecOps Vulnerability assessment.
SecOps Vulnerability is an add-on to SaltStack Enterprise that manages vulnerabili-
ties on all the systems in your environment. For more on SecOps Vulnerability, see
SecOps Vulnerability. Note: A SecOps Vulnerability license is required.
13.3.2 Resource access
The Resource Access tab allows you to define resource access for targets and jobs. A target is the group of minions,
masters, or a single master that a job’s Salt command applies to. Jobs are used to run remote execution tasks, apply
states, and start Salt runners.
The different levels of resource access are described below.
Targets
Read Only Role can view the indicated target and its details, but cannot edit or delete it.
Read/Write Role can view and edit the indicated target.
Read/Write/Delete Role can view, edit, and delete the indicated target.
For more on targets, see Minions and targets.
Jobs
Read Only Role can view the indicated job and its details, but cannot edit or delete it, or run the job.
Read/Run Role can view and run the indicated job.
Read/Run/Write Role can view and edit the indicated job, as well as run it.
Read/Run/Write/Delete Role can view, edit, and delete the indicated job, as well as run it.
For more on jobs, see Jobs.
Other resource types
Access to the following resource types must be defined using the Enterprise API. See API Permission values, or contact
an administrator for assistance.
• Files in the file server
• Pillar data
• Authentication configuration
All other resource types, (excluding jobs, targets, and those listed above) do not require any specific resource access
settings.

13.3.3 Difference between permitted tasks and resource access
A permitted task is broad category of allowed actions, whereas resource access is more granular, allowing you to
specify a particular resource (such as a job or target) the action can be run against, as illustrated in the following
diagram.
In the following example, a role can run test.ping on the Linux target group. The role has the following permis-
sions settings:
• Read access to the Linux target
• Read/Run access to a job that includes the test.ping command
Cloned roles inherit permitted tasks from the original role by default. Cloned roles do not inherit resource access,
which must be defined separately. See Assigning access to a job or target.
13.3. Reference 69
13.3.4 Types of roles
SaltStack Enterprise ships with a number of built-in roles that cannot be deleted. It also gives you tools to create
custom-defined roles for your own unique needs.
Built-in roles
SaltStack Enterprise includes the following built-in roles:

User This is the default role assigned to all new local users and LDAP users. The User role covers fundamental
permissions, such as Read access, needed to perform many basic functions. Users assigned this role can view
and run jobs, as well as view job history, job returns, and reports for certain minions and job types, limited to
the role’s resource access settings.
For a list of all default User role permissions, see Built-in roles default settings.
Administrator This role needs access to more advanced tools than the user role and thus can access System Admin-
istration. Administrators can view (and in some cases, edit) sensitive data found in user settings and pillar. The
role can create, update, and delete resources such as files, jobs, and targets. Administrators can also manage
keys as needed when configuring new nodes.
For a list of all default Administrator permissions, see Built-in roles default settings.
Superuser Superusers can perform any operation in SaltStack Enterprise, which includes accessing System Ad-
ministration. root is assigned to the Superuser role. The role cannot be deleted or cloned. You can add any
group or user to the role, but you cannot modify any of the role’s other settings. Only advanced users should
be added to the Superuser role, as it effectively bypasses permissions restrictions.
Custom-defined roles
To supplement SaltStack Enterprise’s built-in roles, you can create custom roles. Custom roles help you define more
targeted resource access for different user profiles based on your organization’s needs. For example, you might create
a CentOS Administrator role for users responsible for administering CentOS nodes, and a RedHat Administrator role
for users responsible for RedHat nodes.
13.4 See also
• Built-in roles default settings

• Advanced roles editor
• Jobs
• Permissions in the eAPI

CHAPTER
FOURTEEN
ADVANCED PERMISSIONS
14.1 Overview
In some situations, you may need to configure more granular role permissions, beyond the options available through
the Tasks tab in the Roles editor. The Advanced tab provides more thorough control over tasks a role can complete.
14.2 How to set Advanced permissions
Note: The following steps should be completed by an experienced Salt administrator who understands your overall
infrastructure.
14.2.1 Defining advanced permissions
1. Go to Menu > System Administration > Roles and select the Advanced tab.
2. Ensure the required role is selected in the left panel.
3. Select or deselect permissions as needed, choosing from Read, Run, Write, or Delete for a range of functional
areas.
For more on permissions, see Permission types. For more on available resource types and functional areas, see
Items.
71
Minimum recommended permissions for typical user operation are highlighted in blue, as demonstrated in
the following figure.
This figure shows two minimum recommended boxes on the left, one selected and the other unselected, com-
pared with two normal boxes on the right.
4. Click Save.
14.3 Reference
14.3.1 Permission types
Read Role can view a given type of resource or functional area. For example, if you assign the role Read Target
Groups, the role can view the targets you specify, as well as details about each target.
Run Role can run a given type of operation. The type of operation permitted can vary, for instance you can assign
permission to run arbitrary commands on minions, or to run commands on Salt Masters.
Write Role can create and edit a given type of resource or functional area. For example, you might assign Write
File Server to an advanced user role, so the role can create or edit files in the file server. Users with Write
access can edit resources they have created, without needing any specific resource access settings.
Delete Role can delete a given type of resource or other item in a given functional area. For example, you might
assign Delete Pillar to a role, so the role can delete a pillar that’s no longer in use. Users with Delete
permission can delete resources they have created, without needing any specific resource access. settings.
14.3.2 Items
When setting permissions for a role in the advanced editor, the above actions can apply to the following resources
or functional areas.
Resource type / Func- Description See also

tional area
All Minions Commands Run commands on the All Minions target. The All Min- Minions and targets
ions target can vary based on the combination of min-
ions the role has permission to access.
Audit Log The audit log is a record of all activity in SaltStack En- See RPC Audit endpoint,
terprise that includes details of each user’s actions. or contact an administra-
tor for assistance.
Commands A command is the task (or tasks) executed as part of Jobs
a job. Each command includes target information, a
function, and optional arguments.
Continued on next page
72 Chapter 14. Advanced permissions

Table 14.1 – continued from previous page

tional area
File Server The file server is a location for storing both Salt-specific File Server
files, such as top files or state files, as well as files that
can be distributed to minions, such as system configu-
ration files.
Groups Groups are collections of users who share common Roles and permissions
characteristics, and need similar user access settings.
Jobs Jobs are used to run remote execution tasks, apply Jobs
states, and start Salt runners.
License Read Your license includes usage snapshots, as well as de- See RPC License endpoint,
tails such as number of masters and minions licensed or contact an administra-
for your installation, and when the license expires. tor for assistance.
Master Configuration The Master Configuration file contains details about the
Salt Master, such as its master ID, publish port, caching
behavior, and more.
Master Resources The Salt Master is a central node used to issue com-
mands to minions.
Metadata auth The AUTH interface is used for managing users, See RPC Auth endpoint, or
groups, and roles through the RPC API. contact an administrator
for assistance.
Minion Resources Minions are nodes running the Salt Minion service, Minions and targets
which can listen to commands from a master and per-
form the requested tasks.
Pillar Pillars are structures of data defined on the Salt Mas- Pillars
ter and passed through to one or more minions, using
targets. They allow confidential, targeted data to be se-
curely sent only to the relevant minion.
Returner Data Returners receive the data minions return from exe-
cuted jobs. They allow for the results of a Salt command
to be sent to a given data store such as a database or log
file for archival.
Roles Roles are used to define permissions for multiple users Roles and permissions
who share a common set of needs.
Runner Commands A command is the task (or tasks) executed as part of Jobs
a job. Each command includes target information, a
function, and optional arguments. Salt runners are
modules used to execute convenience functions on the
master.
Compliance Assessment An assessment is an instance of checking a collection SecOps Compliance -
of nodes for a given set of security checks, as specified Note: A SecOps Compli-
in a SecOps Compliance policy. ance license is required.
Compliance Policy Compliance policies are collections of security checks, SecOps Compliance -
and specifications for which nodes each check applies Note: A SecOps Compli-
to, in SecOps Compliance. ance license is required.
Compliance Remediation Remediation is the act of correcting noncompliant SecOps Compliance -
nodes in SecOps Compliance. Note: A SecOps Compli-
ance license is required.
Compliance Content In- Ingesting SecOps Compliance content is to download SecOps Compliance -
gest - SaltStack or update the SecOps Compliance security library. Note: A SecOps Compli-
ance license is required.
Continued on next page
14.3. Reference 73
Table 14.1 – continued from previous page

tional area
Compliance Content In- Custom Compliance content allows you to define your SecOps Compliance -
gest - Custom own security standards, to supplement the library of se- Note: A SecOps Compli-
curity benchmarks and checks built into SecOps Com- ance license is required.
pliance. Ingesting custom content is to upload custom
checks and benchmarks.
Compliance Custom Con- Custom Compliance content allows you to define your SecOps Compliance -
tent own security standards, to supplement the library of se- Note: A SecOps Compli-
curity benchmarks and checks built into SecOps Com- ance license is required.
pliance.
Schedules Schedules are used to run jobs at a predefined time or Schedules
specific interval.
SSH Commands Secure Shell (SSH) commands run on minions that do
not have the Salt Minion service installed.
Wheel Commands Wheel commands control how the master operates, and
are used to manage keys.
Target Groups A target is the group of minions, masters, or a single Minions and targets
master that a job’s Salt command applies to.
Users Users are individuals who have a SaltStack Enterprise Roles and permissions
account with your organization.
Vulnerability Assessment A vulnerability assessment is an instance of scanning a SecOps Vulnerability -
collection of nodes for vulnerabilities as part of a Sec- Note: A SecOps Vul-
Ops Vulnerability policy. nerability license is
required.
Vulnerability Policy Vulnerability policies are collections of advisories, and SecOps Vulnerability -
specifications for which nodes each advisory applies to, Note: A SecOps Vul-
in SecOps Vulnerability. nerability license is
required.
Vulnerability Remedia- Remediation is the act of patching vulnerabilities in SecOps Vulnerability -
tion SecOps Vulnerability. Note: A SecOps Vul-
nerability license is
required.
Vulnerability Content In- SecOps Vulnerability content is a library of advisories SecOps Vulnerability -
gest based on the latest Common Vulnerabilities and Ex- Note: A SecOps Vul-
posures (CVE) entries. Ingesting SecOps Vulnerability nerability license is
content is to download the latest version of the content required.
library.
Read Background Jobs Background jobs run asynchronously with respect to See RPC background jobs
Status an API call. Examples include synchronizing with an endpoint, or contact an
LDAP server and running license usage snapshots. administrator for assis-
tance.
14.3.3 Resource access in the API
Access to the following resource types must be defined using the Enterprise API. See API Permission values, or contact
an administrator for assistance.
• Files in the file server
• Pillar data
• Authentication configuration

All other resource types, (excluding jobs, targets, and those listed above) do not require any specific resource access
settings.
14.4 See also

• Built-in roles default settings
14.4. See also 75


CHAPTER
FIFTEEN
BUILT-IN ROLES DEFAULT SETTINGS
15.1 Overview
SaltStack Enterprise includes the following built-in roles:

• User
• Administrator
• Superuser
15.2 Reference
Built-in roles include default permissions as follows.

For a description of the resources and functional areas included the following tables, see Items.
15.2.1 User
Resource type / Functional area Read Run Write Delete

Background jobs X
Commands X
File Server X
Jobs X X
License X
Master configuration X
Master File server X
Master X
Metadata Auth X
Minion X
Returner X
Schedule X X X
SecOps Compliance Policies Note: a license is required X
SecOps Vulnerability Policies Note: a SecOps Vulnerability license is required X
Targets X
All Minions Commands X
77
15.2.2 Administrator
Resource type / Functional area Read Run Write Delete

Background jobs X
Commands X X X
Runner commands X
SSH commands X X X X
Wheel commands X
File Server X X X
Jobs X X X X
License X
Metadata Auth X X
Minion X X
Pillar X X X
Returner X X
Role X X X
Schedule X X X
SecOps Compliance Policies Note: a SecOps Compliance license is required XX
SecOps Vulnerability Policies Note: a SecOps Vulnerability license is required X
Targets X X X
All Minions Commands X
Users X X X
15.2.3 Superuser
The Superuser role can perform any operation in SaltStack Enterprise.
15.3 See also

• Advanced roles editor
78 Chapter 15. Built-in roles default settings

CHAPTER
SIXTEEN
REPORTS
16.1 Overview
The Reports workspace provides an overview of important metrics in your SaltStack Enterprise environment, such
as number of licenses available and used, or the Salt version installed on different nodes. You can view reports under
the Home screen. Reports update automatically to reflect the current state of your system.
Report data is provided for all minions. However, some reports can be filtered by target group.
requested tasks. A target is the group of minions, masters, or a single master that a job’s Salt command applies to.
The Salt Master is a central node used to issue commands to minions. For more on minions and targets, see Minions
and targets.
In the Reports workspace you can download reports in either JSON or CSV format.
16.2 How to use Reports
In the Reports workspace, you can view key metrics in your SaltStack Enterprise environment. The workspace
provides downloads and a graph for each report type. You can also adjust the columns displayed for each report, as
well as filter column data.
16.2.1 Viewing reports
1. In SaltStack Enterprise, go to Home.

The Home screen contains the Reports workspace.
2. Select the report you want to view. See Types of reports.
Changing table columns
1. Select a report and click the Column button in the lower left corner.
2. In the resulting menu, select or deselect column names to choose which columns to include in the table view.
Note: You can also filter each column by selecting its filter icon , or sort a column by selecting the
column name.
79
16.2.2 Downloading reports
1. In the Reports workspace, select the report you want to download.

2. Go to More actions and select either JSON or CSV.
The report begins downloading in your browser.
16.3 Reference
16.3.1 Types of reports
Enterprise Console includes several reports to provide an overview of important metrics in your SaltStack Enterprise
environment.
Report data is provided for all minions. However, some reports can be filtered by target group.
requested tasks. A target is the group of minions, masters, or a single master that a job’s Salt command applies to.
For more on minions and targets, see Minions and targets.
80 Chapter 16. Reports

Report Description
Key state State of all minion keys. A minion key allows encrypted communication between a
Salt Master and Salt Minion. For more on keys, see Minion Keys.
Licenses Number of SaltStack Enterprise licenses used and number of licenses available This
report includes a line graph that shows a history of license usage over time. The
License report cannot be downloaded. For more on licensing, talk to your adminis-
trator.
Master version Salt Master version installed on all masters. The Salt Master is a central node used
to issue commands to minions.
Minion version Salt Minion version installed on minions within the selected target group.
OS version Operating system installed on nodes within the selected target group.
Presence Presence status of minions in the selected target group. Presence indicates if Salt-
Stack Enterprise has received any job data from a minion recently, within a defined
interval. For more on presence, see Minion presence.
16.4 See also

• Minion Keys
• Minion presence
16.4. See also 81

82 Chapter 16. Reports

CHAPTER
SEVENTEEN
PILLARS
17.1 Overview
Pillars are structures of data defined on the Salt Master and passed through to one or more minions, using targets.
They allow confidential, targeted data to be securely sent only to the relevant minion. Pillars are useful for limiting
user access to private data, for example to allow a user to run a job that requires authentication to an external service.
In this case, you would assign the user access to the given job and target, but not to the pillar containing sensitive
authentication details.
Pillar data is encrypted in the SaltStack Enterprise database, and is not stored in plain text. It is encrypted during
transmission, and made visible only to minions specified in the pillar target settings. For more on assigning pillar to
a target, see Assigning pillar.
A target is the group of minions, masters, or a single master that a job’s Salt command applies to. Minions are nodes
running the Salt Minion service, which can listen to commands from a master and perform the requested tasks. For
more on minions and targets, see Minions and targets.
Pillar data can be stored in a private pillar in the Pillars workspace, in a job’s settings, or in other pillar roots in the
SaltStack Enterprise backend server. Pillar data stored within a job is less secure than data in a standard pillar, as
any user with permission to access the job can also view the pillar data. Jobs are used to run remote execution tasks,
apply states, and start Salt runners. For more on jobs, see Jobs.
For more on pillar in Salt, see Salt pillar walkthrough (https://docs.saltstack.com/en/latest/topics/tutorials/pillar.
html).
17.2 How to use Pillars
In the Pillars workspace you can create new pillars, and assign pillars to targets. When you assign a pillar to a target,
you can also choose to refresh the pillar.
17.2.1 Creating a pillar
1. Go to Elements > Pillars and click Create.

2. Enter pillar data in JSON format and click Save.
Note: Pillar names do not have to be unique. This might result in different items displaying with the same name in
the Web Console.
83
17.2.2 Assigning pillar
1. In the Pillars workspace, select a pillar.

2. Click Update Targets.
3. In the dialog, select targets you want to apply the pillar to.
In addition to selecting a target, select Refresh pillar to make the pillar available to the selected target imme-
diately.
4. Click Save.
The pillar data is now available to all minions in the selected target.
Note: You can also assign a pillar to a target in the Targets Workspace. See Minions and targets.
17.3 Reference
17.3.1 Pillars and the All Minions target
The All Minions target is read-only, and cannot be assigned pillar data. To assign pillar data to all minions, create a
new target that matches all minions (*). For more on creating targets, see Minions and targets.
17.3.2 Value precedence
If the same pillar data is defined in multiple sources, SaltStack Enterprise selects the data to apply in the following
order of precedence:
1. Values passed directly on the job
2. Values in Enterprise Console (in the Pillars workspace)
3. Values in other pillar roots
You can change this behavior by adjusting the order of pillar_roots in the Salt Master configuration.
17.3.3 Pillar data format
External pillar data must be in JSON format. YAML is not currently supported.
17.3.4 Pillar dependencies
Files
Pillar data is useful for passing data into states, reactors, and other types of files. Make sure when creating or
updating pillar data to also update pillar references in any corresponding files. See File Server.
Targets
Pillar data attached to a target is used when associated jobs run on the target. Make sure when updating pillar data
to also refresh pillar on its associated targets. See Assigning pillar.
84 Chapter 17. Pillars

17.4 See also
• Minions and Targets

• Jobs
• File Server
17.4. See also 85

86 Chapter 17. Pillars

CHAPTER
EIGHTEEN
FILE SERVER
18.1 Overview
The file server is a location for storing both Salt-specific files, such as top files or state files, as well as files that can
be distributed to minions, such as system configuration files. In the file server, you can view, author, and save state
files (YAML), modules, and text files.
Files in SaltStack Enterprise are useful for configuring states you can then apply through jobs. Jobs are used to run
remote execution tasks, apply states, and start Salt runners.. For more on jobs, see Jobs.
Files are also used to iterate over pillar entries in an associated pillar. Pillars are structures of data defined on the
Salt Master and passed through to one or more minions, using targets. They allow confidential, targeted data to be
securely sent only to the relevant minion. See Pillar.
18.2 How to use the file server
In the file server, you can create new files and clone existing ones. You can also edit and delete files.
18.2.1 Creating a file
1. Go to Elements > File Server and click Create.

2. Under base, enter the base environment name.
87
3. Under Path Name, enter the path to the file, and file name.
Note: File names do not have to be unique as long as the files are in different paths or environments. This
might result in different items displaying with the same name in the Enterprise Console.
4. Enter the file body and click Save.

You can now view the file in the file server. Only Superusers can view files created by other users.
18.2.2 Cloning a file
1. Under File Server, select the file you want to clone.

2. Click Clone.
A copy of the file is now available in the file server, with -2 appended to the file name.
18.2.3 Deleting a file
1. Under File Server, select the required file.

2. Click Delete.
3. In the confirmation dialog, click Confirm.
18.3 Reference
18.3.1 Integration with existing file servers
If you have existing file server backends configured, such as Git or S3, they continue to work as expected, and jobs
created and executed in Enterprise Console can use these backends with no additional configuration.
If you plan to use the SaltStack Enterprise file server in conjunction with other file servers, be aware that files that
exist in Enterprise Console take precedence if they also exist in other file servers.
fileserver_backend:
- sseapi
- roots
- git
You can change this behavior by re-ordering the entries in the fileserver_backend section in the /etc/
salt/master.d/raas.conf file.
18.3.2 Environments
SaltStack Enterprise file server provides the ability to define multiple file environments.
Environments let you isolate files that have the same path and name. By default, files and pillar data exist in the base
environment. This is the environment you select when you create a state run job.
88 Chapter 18. File Server

You can select the environment in which you want to create a file by specifying it during creation. See Creating a
file.
18.3.3 File server access
Users do not need file server privileges to run jobs. For example, if you create a job that runs the apache/init.
sls file (state.apply apache), users with access to this job can run it even though they can’t view, edit, or
delete the apache/init.sls file directly.
Only Superusers can view files created by other users. Only the Superuser and Admin default roles are granted
access to view and make changes to the file server. See Roles and permissions.
18.4 See also
• Pillar
• Jobs
18.4. See also 89

90 Chapter 18. File Server

CHAPTER
NINETEEN
SECOPS COMPLIANCE
Note: SecOps Compliance is a SaltStack Enterprise add-on that provides automated compliance detection and
remediation for your infrastructure.
A SecOps Compliance license is required.
19.1 Overview
SecOps Compliance is an IT infrastructure security and compliance solution that combines security with IT opera-
tions all in a single platform. Its security library contains the latest security standards based on industry best practice
hardening guides such as CIS, and more. It uses the library to not only assess your infrastructure security, but also
to remediate noncompliant systems instantly.
Note: SaltStack Enterprise also include the SecOps Vulnerability add-on, for vulnerability scanning and remedia-
tion. For more on SecOps Vulnerability, see SecOps Vulnerability.
SecOps Compliance harnesses Salt’s powerful configuration management and remote execution capabilities to bring
all of your infrastructure assets to compliance with a range of industry-wide security benchmarks. It integrates
with SaltStack Enterprise to apply security measures at scale, while respecting custom exceptions based on your
organization’s needs.
19.1.1 Policies
To secure your infrastructure assets with SecOps Compliance, start by defining policies. SecOps Compliance provides
different industry benchmarks to choose from including checks for CIS and more. For more on defining policies, see
Building a policy.
Each benchmark includes a collection of security checks. You can choose to apply all available checks for a given
benchmark, or use only a subset of available checks. Using a subset of checks is useful for customizing SecOps
Compliance for your unique infrastructure needs, for example if remediating a given check poses the risk of breaking
a known dependency. For more on benchmarks and checks, see Benchmarks.
19.1.2 Assessments and remediation
SecOps Compliance uses your compliance policy as the basis for assessing your infrastructure’s security. Following
each assessment, SecOps Compliance provides a report highlighting any noncompliant systems, along with the
recommended remediation. See Running an assessment.
91
Note: SecOps Compliance does not make any changes during the assessment.
Following an assessment, you can remediate any non-compliant nodes. For convenience, SecOps Compliance allows
you to remediate all at once, or remediate only a subset of either nodes or checks. For more on remediation, see
Remediating all checks.
19.1.3 Customization
To customize SecOps Compliance for your organization’s needs, you can exempt certain checks and nodes from
remediation. You can also insert variable values to enforce requirements that are stricter than industry standards.
For more on exemptions, see Adding exemptions.
Another customization method is to configure user permissions to allow only certain users to remediate, while
allowing others to assess or define policies. This offers you complete control over every action taken. For more on
permissions, see Roles and Permissions.
19.2 How to use SecOps Compliance
To use SecOps Compliance, first define a policy, then scan systems against the policy. The scan detects non-compliant
systems, and allows you to remediate issues instantly. Additionally, you can enter exemptions and specify user
permissions to ensure all paths to remediation are customized for your organization’s needs.
Note: This section describes how to use SecOps Compliance in the Enterprise Console. However, you can also use
SaltStack Enterprise through the Enterprise API. See the Sec API interface, or contact an administrator for assistance.
19.2.1 Building a policy
1. In the SecOps Compliance home page, click Create policy.

2. Enter the policy name and select a target to apply the policy to. Then click Next.
Note: A target is the group of minions, masters, or a single master that a job’s Salt command applies to.
Minions are nodes running the Salt Minion service, which can listen to commands from a master and perform
the requested tasks. For more on minions and targets, see Minions and Targets.
3. In the Benchmarks tab, select all benchmarks you want to include in the policy, then click Next.
Note: If no benchmarks display, you may need to download compliance content. See Updating the security
library, or contact your administrator for assistance.
4. In the Checks tab, select all checks you want to include in the policy. The available checks are determined by
the selected Benchmarks. A detailed description of each check displays in the right panel when selected.
Custom checks include a user icon , in contrast with SaltStack checks .
For more on understanding checks, see Checks.
To filter the list, click the Filter button |filtericonpdf|.
92 Chapter 19. SecOps Compliance

Note: Policies that include many checks might result in long processing times during assessment. This could
also delay other processes, such as jobs running, in SaltStack Enterprise. Make sure to include only the checks
you need, and account for extra time required to run large assessments.
5. Click Next.
6. In the Variables tab, enter or modify variables according to your needs, or accept the default values. Then
click Next.
Note: The values you enter define how SecOps Compliance performs the selected checks. The default values
are recommended. For more on variables, see Variables.
7. In the Schedule screen, define schedule frequency and click Save. For more on defining schedule settings, see
Schedules.
Editing a policy
1. In the SecOps Compliance home page, select the policy you want to edit.
2. In the policy screen, click Edit policy in the upper-right corner.
3. Edit the policy as needed and click Save.
Updating the security library
1. In the upper-right corner of the Enterprise Console, click the Menu .

2. Go to System administration > SecOps.
3. Under Compliance Content - SaltStack, click Check for updates.
19.2.2 Running an assessment
Note: Policies that include many checks might result in long processing times during assessment. This could also
delay other processes, such as jobs running, in SaltStack Enterprise. Make sure to account for extra time required to
run large assessments.
1. In the SecOps Compliance home page, select a policy.

2. In the policy home page, click Run assessment. The Activity screen opens.
Completed assessments are listed in the Activity screen along with their status, Job ID (JID), and other infor-
mation.
Note: During the assessment, no changes are made. You will have the ability to remediate any issues later.
See Remediating all checks.
19.2. How to use SecOps Compliance 93

Viewing assessment results
1. In the SecOps Compliance home page, select a policy.

2. The policy home page shows results from the most recent assessment, organized by check. To filter the list,
click the Filter button . You can also select a column heading to sort results, for example you might
sort the Not compliant column to view non-compliant nodes first.
You can select the Minions tab to view assessment results by minion.
Note: Before you can view assessment results, you must first run the assessment. See Running an assessment.
Understanding assessment results
For an assessment results reference, see Assessment results.
Downloading the assessment report
1. In the SecOps Compliance home page, select a policy to view the latest assessment results.
2. In the policy home page, go to the Report tab and click Download.
3. In the resulting dropdown, select JSON.
Your web browser begins downloading the report.
19.2.3 Remediating all checks
1. In the SecOps Compliance home page, select a policy to view the most recent assessment results.
2. In the Checks tab, click Remediate all in the upper-right corner.
3. In the confirmation dialog, click Remediate all.
Note: Any exempted checks or minions are not remediated when you run Remediate all.
Remediating by check
1. In the policy screen, select a check to open the check description.

2. Scroll down past the check description to a list of results from your last assessment. The results are ordered
by minion.
3. Select all minions you want to remediate for the active check.
4. Click Remediate.

Remediating by minion
1. In the policy screen, go to the Minions tab and select a minion.

2. Select all checks you want to remediate for the active minion.
3. Click Remediate.
19.2.4 Adding exemptions
1. In the policy screen, select the checks you want to exempt from remediation.
2. Click Add exemption.
3. Enter the reason for exemption and click Add exemption to confirm. You can always remove the exemptions
later if needed.
Exempted items will not be remediated. If a remediation runs against a policy that includes the exempted item,
the remediation is skipped for that item.
Note: You can add an exemption either before or after running the assessment. You can also define a cus-
tomized policy that excludes checks based on your needs. See Building a policy.
Adding exemptions by minion
1. In the policy screen, go to the Minions tab.

2. Select the minions you want to exempt from remediation.
later if needed.
Removing an exemption
1. In the policy screen, go to the Exemptions tab.

2. Scroll up and down the page to view a list of all exemptions.
Note: There might be more exemptions off-screen when you first open the Exemptions tab. Keep scrolling
to the bottom of the screen to view all exemptions.
3. Click the dropdown for the exemption you want to remove.
19.2. How to use SecOps Compliance 95

This opens a list of all affected minions.

4. Click Remove exemption.
5. In the confirmation dialog, click Remove exemption.
19.2.5 Defining SecOps Compliance permissions
• Go to the permissions editor to modify SecOps Compliance permissions. For more on SaltStack Enterprise
roles and permissions, see Roles and Permissions.

19.3 Reference
19.3.1 The SecOps Compliance content library
The SecOps Compliance content library consists of pre-built, industry best-practice security and compliance content,
including:
• CIS
Note: The security library updates automatically as security standards change.
19.3.2 Compliance policies
Compliance policies are collections of security checks, and specifications for which nodes each check applies to, in
SecOps Compliance. Policies can also include schedules, as well as specifications for handling exemptions.
Each component of a security policy is described in more detail below.
Target
A target is the group of minions, masters, or a single master that a job’s Salt command applies to. When you choose
a target in SecOps Compliance, you define the nodes you want to run security checks against. You can choose an
existing target or create a new one. For more on targets, see Minions and Targets.
Benchmarks
Benchmarks are categories of security checks. SecOps Compliance benchmarks are defined by widely-accepted
experts, while custom benchmarks can be defined by your own organization’s standards. You can use benchmarks
to help create a range of different policies optimized for different groups of nodes. For example, you might create
an Oracle Linux policy that applies CIS checks to your Oracle Linux minions, and a Docker policy that applies CIS
checks to your Docker minions.
For more on custom benchmarks, see SecOps Compliance Custom Content.
SecOps Compliance helps simplify the process of defining your security policy by grouping security checks by bench-
mark.
Checks
A check is a security standard that SecOps Compliance assesses for compliance. The SecOps Compliance library
updates checks frequently as security standards change. In addition to checks included the SecOps Compliance
content library, you can create your own custom checks. Custom checks include a user icon , in contrast with
SaltStack checks . For more on custom checks, see secops-custom-content.
Each check includes the following information fields.
Note: Some of the following items are defined for each check, while others are defined for one or more benchmarks.
Description Brief description of the check.

Action Brief description of the action that will be taken upon remediation.
19.3. Reference 97
Break Used for internal testing purposes only. For more information, contact your administrator.
Global description Detailed description of the check.
Osfinger List of osfinger values the check is implemented for. osfinger is found in grains.items for each minion.
It identifies the minion’s operating system and major release version. Grains are an interface that derives
information about the underlying system. Grains are collected for the operating system, domain name, IP
address, kernel, OS type, memory, and many other system properties. For more on grains, see Salt grains
reference (https://docs.saltstack.com/en/latest/topics/grains/).
Profile List of configuration profiles for different benchmarks. These configuration profiles target a machine’s dif-
ferent roles within an environment (for example, on a server or a workstation), and different levels of security
in contrast with practical use.
Rationale Description of the rationale for implementing the check. This includes reasons why you might want to
implement the check.
Refs Compliance cross-references between benchmarks.
Remediate (Not included in all checks) - Value that indicates whether SecOps Compliance is capable of remediating
noncompliant nodes, as not all checks include specific, actionable remediation steps. For example, SecOps
Compliance doesn’t remediate CIS 1.1.6: Ensure separate partition exists for /var since no one universal method
exists for repartitioning every system. False indicates a check that can’t be remediated. When True (default),
this field is not displayed.
Remediaton Description of how any noncompliant systems will be remediated, if applicable. Note that some checks
don’t include specific, actionable remediation steps. See Remediate above.
Scored CIS benchmark Scored value. Scored recommendations impact the target’s benchmark score, while recom-
mendations that are not scored do not affect the score. True indicates scored and False indicates not scored.
State file Copy of the Salt State that will be applied to execute the check and if applicable, the subsequent remedi-
ation.
Variables
Variables in SecOps Compliance are used to pass values into the Salt States that make up security checks. For best
results, use the default values provided.
For more on Salt States, see the Salt States tutorial (https://docs.saltstack.com/en/latest/topics/tutorials/starting_
states.html).
Schedules
Note: In the schedule editor, the terms “Job” and “Assessment” are used interchangeably. When you define a
schedule for the policy, you are scheduling the assessment only - not the remediation.

Note: When defining an assessment schedule, you can choose from the additional Not Scheduled (on demand)
option. If you select this option, you choose to run a one-time assessment, and no schedule is defined.
19.3.3 Activity status
In your policy home page, the Activity tab shows a list of completed or in-progress assessments and remediations.
It includes the following statuses.
finished running.
the requested tasks. The Salt Master is a central node used to issue commands to minions.
You can track all activity in SaltStack Enterprise, including assessments and remediations, in the SaltStack Enterprise
main Activity workspace. See Activity.
19.3.4 Assessment results
Refer to the following to understand assessment results. For more on how to access assessment results, see Viewing
assessment results.
Return statuses
Following a remediation, SecOps Compliance labels each system with one of the following return statuses.
Compliant Setting is in its intended state compared to the standard or benchmark.
Not compliant Setting is not in its intended state compared to the standard or benchmark. Further investigation
and possible remediation are recommended.
Not Applicable The setting is not applicable to this system, for example, if a running a CentOS check on AIX.
Unknown Assessment or remediations have not been run.
Error SecOps Compliance encountered an error while running the assessment or remediation.
19.4 See also

• secops-custom-content
• SecOps Vulnerability
• Jobs
19.4. See also 99

• Schedules
• Sec API interface

CHAPTER
TWENTY
SECOPS COMPLIANCE CUSTOM CONTENT
20.1 Overview
Custom Compliance content allows you to define your own security standards, to supplement the library of security
benchmarks and checks built into SecOps Compliance. This is useful for enhancing SecOps Compliance policies to
fit your internal requirements.
A check is a security standard that SecOps Compliance assesses for compliance. Benchmarks are categories of
security checks.
SecOps Compliance includes a Custom Content Software Development Kit (SDK) you can use to create, test, and
build your own custom security content. You can import your custom security content to use alongside SecOps
Compliance’s built-in security library for assessment and remediation. This also allows you to version your content
using a version control system of your choice.
20.2 How to use custom content
To use custom checks, first initialize the SecOps Compliance Custom Content SDK. The SDK includes sample files
you can modify to create your own custom checks, as well as benchmarks. The SDK also includes a Docker-based
testing environment where you can test your new content.
Once your custom content is created and tested, you can build a content file and import it into SecOps Compliance to
begin assessing and remediating. Custom checks include a user icon , in contrast with SaltStack checks . SecOps
Compliance tracks dependencies between policies and your custom content, and provides a list of dependencies that
might break if you delete the content.
20.2.1 Initializing the SDK
1. Download the SDK binary for your Operating System from https://enterprise.saltstack.com/, under the Salt-
Stack SecOps configuration tab.
2. From the command line, navigate to the directory containing the file and run the following according to your
OS.
• Mac OS or Linux
./secops_sdk init
• Windows
101
secops_sdk.exe init
No output shows. This is expected. Your directory now contains the following folders and files:
• benchmarks
• salt/locke/custom
• sample_tests
• README.md
For more on these folders and files, see Folders and files.
3. (Optional) Commit changes to a version-controlled repository.
20.2.2 Creating custom checks
Note: Initializing the SDK is a prerequisite to creating custom content. See Initializing the SDK
1. In the Custom Content SDK, go to salt/locke/custom. This directory contains various subdirectories
with sample state (.sls) and meta (.meta) files.
Note: All custom checks must be configured in both a state (.sls) and corresponding meta (.meta) file.
2. Make a copy of both a sample state (.sls) and its corresponding meta (.meta) file, renaming both with a
descriptive name for your custom check.
Both files associated with a check must be in the same directory and start with the same name, for example:
• my_first_check.meta
• my_first_check.sls
You can save these two files together in any subdirectory of salt/locke/custom.
3. Edit the contents of the meta file to customize the check based on your needs. The file is written in YAML. For
a list of the different options included in the file, see Check meta files.
Note: Check meta files contain references to different benchmarks. When creating custom content, make
sure to include all associated benchmarks in your check meta file.
4. Edit the contents of the state file. For more information, see Check state files.
5. Ensure both files are saved in the same directory.
You have now completed the minimum steps required to create a custom check. You can continue to test the
check, commit to version control, or build your content library.
20.2.3 Creating custom benchmarks
Note: Initializing the SDK is a prerequisite to creating custom content. See Initializing the SDK
102 Chapter 20. SecOps Compliance Custom Content

1. In the Custom Content SDK, go to the benchmarks directory. This contains a sample benchmark meta
(.meta) file.
2. Make a copy of Sample_Benchmark.meta, renaming it with a descriptive name for your benchmark.
3. Edit the contents of the meta file to customize the benchmark based on your needs. The file is written in YAML.
For a description of the different options included in the file, see Custom benchmark files.
20.2.4 Testing custom content
Note: Installing Docker is a prerequisite to the following. For more on downloading and installing Docker, see the
Docker installation documentation.
1. Once you have created your custom content, open the command line and navigate to the Custom Content SDK
sample_tests directory.
2. Build a docker image of CentOS7 with Salt for testing.
./build.sh
3. Start the testing container.
./up.sh
4. Run sample tests on checks you created in the salt/locke/custom directory. You can execute custom
checks as you would normal Salt states, for example:
./test.sh salt-call --local state.apply locke.custom.mounts.my_first_check

˓→test=True
For more testing examples, see Test Custom Content in the SDK README. For more on Salt States, see the Salt
documentation.
5. When testing is complete, shut down the testing container.
./down.sh
20.2.5 Building the custom content library
1. Once you have created your custom content, open the command line and navigate to the Custom Content SDK
root directory.
2. Build your custom content library.
./secops_sdk build -a
The SDK root directory now includes the _dist subdirectory. This includes two tar.gz files you can use
to import your content through Enterprise Console or Enterprise API. For a description of all files included in
the directory, see Folders and files.
20.2. How to use custom content 103

20.2.6 Importing custom content
1. In Enterprise Console, go to > System Administration > SecOps.

2. Click Check for Updates.
Note: If you have already downloaded SecOps Compliance content during your current session, you can skip
this step.
3. Click Upload Package and select the .tar.gz file from your file explorer.
Note: To make your custom checks easier to navigate, use the file containing a timestamp in the filename.
For more on files, see Folders and files.
Your custom content is now available in SecOps Compliance for building policies, running assessments, and
remediating your systems. Custom checks include a user icon , in contrast with SaltStack checks .
Note: You can also import content using the Enterprise API, or alternatively, through the command line
during installation. See Sec API interface or https://enterprise.saltstack.com/.
20.2.7 Deleting custom checks
1. In Enterprise Console, go to SecOps > Checks.

2. Click the menu next to the check you want to delete, and click Delete.
Note: Only custom content can be deleted. Custom content includes a user icon , in contrast with SaltStack
content .
3. In the Delete Check dialog, under In Use, review the list of policies and benchmarks that include the check.
This is useful for predicting any dependencies in your environment that might break if you delete the check.
When you have finished reviewing dependencies in use, click Next.
4. Under Delete Check > Warning, click Delete. The dialog confirms the check was deleted.
5. Click Done to close the dialog.
20.2.8 Deleting custom benchmarks
1. In Enterprise Console, go to SecOps > Benchmarks.

2. Click the menu next to the check you want to delete, and click Delete.
Note: Only custom content can be deleted. Custom content includes a user icon , in contrast with SaltStack
content .

3. In the Delete Benchmark dialog, under In Use, review the list of policies and checks associated with the bench-
mark. This is useful for predicting any dependencies in your environment that might break if you delete the
benchmark.
When you have finished reviewing dependencies in use, click Next.
4. Under Delete Benchmark > Warning, click Delete. The dialog confirms the benchmark was deleted.
5. Click Done to close the dialog.
20.3 Reference
20.3.1 Prerequisites
• Download the SecOps Compliance Custom Content SDK. See Initializing the SDK .
• Install Docker. See the Docker installation documentation.
20.3.2 Folders and files
After initializing the SDK, your directory includes the following folders and files:
• benchmarks - contains custom benchmark meta (.meta) files
• salt/locke/custom - contains custom check state (.sls) and meta (.meta) files
• sample_tests - contains example files for testing using Docker
• README.md - provides more detailed information about the SDK
Important files are described in more detail below.
Custom benchmark files
Benchmarks are categories of security checks. SecOps Compliance built-in benchmarks are defined by widely-
accepted experts. However, custom benchmarks can be defined by your own organization’s standards. Each bench-
mark contains a list of recommendations, called checks, and has a corresponding .meta file in the benchmarks
directory. For more on benchmarks in SecOps Compliance, see Benchmarks.
By creating a benchmark meta file, you create a category of checks. You can then add checks to that benchmark by
naming the benchmark in a check meta file under benchmark_id. See Check meta files.
The meta file is written in YAML, and includes the following options you can customize for your content:
name Benchmark name
display_name Name of benchmark as it will appear in the list of benchmarks in SecOps Compliance
desc Benchmark description
Note: In addition to the above options, the meta file also includes a variety of reserved items, such as version,
authority, and ids. Do not modify these reserved items unless instructed by your administrator.
20.3. Reference 105

Custom check files
A check is a security standard that SecOps Compliance assesses for compliance. This is a recommendation associated
with a benchmark. The recommendation provides description, rationale, audit, and remediation information. Each
check is defined by at least two files: a state (.sls) and corresponding meta (.meta) file.
Note: Both files associated with a check must be in the same directory and start with the same name, for example:
• my_first_check.meta
• my_first_check.sls
You can save these two files together in any subdirectory of salt/locke/custom.
Each file type is described in further detail below.
Check meta files
Check meta files include a description of a check, as well as additional details related to the check, such as its version,
applicable Operating Systems, and more. Meta files are written in YAML and use the .meta file extension.
Custom check meta files include the following options:
version Version of the check content. If a change is made to the check, this number should be incremented.
display_name The name of this check as it will appear in the list of checks in Enterprise Console.
global_description A detailed description of the check. This is a chance to give more information than is supplied
through the check and benchmark names.
osfinger List of operating systems that are allowed to run this check. If the host doesn’t have an osfinger value
that matches a value in this list, the assessment result of the check will come back as notapplicable.
refs Cross-reference information about other checks in other benchmarks or security standards that are satisfied
with this check.
benchmark_id List of each benchmark the check belongs to.
Each benchmark entry creates a new section which includes the following sub-options:
type Type of benchmark. Enter custom when defining a custom check not provided by a specific authority.
desc Title of the security recommendation as it will appear in the list of checks in Enterprise Console.
control_id Recommendation number, for example from a corresponding CIS document.
scored This field is modeled after CIS recommendations which may be Scored or Not Scored. CIS recommen-
dations that are Not Scored do not count for or against a security score.“true“ indicates scored and false
indicates not scored. You might choose to score or not score a check, based on your internal needs.
profile CIS and other benchmarks are divided into profiles. For example, the CIS CentOS Linux 7 benchmark
has four profiles, represented as:
profile:
server: level1
workstation: level1
server: level2
workstation: level3
information Description of the check. This may be similar to the check’s global_description field.

rationale Description of the rationale for implementing the check.

remediation Instructions on how to remediate a system in a non-compliant state.
Check state files
Check state files apply Salt states to perform assessments and remediations. A state function is a function contained
inside a state module which can manage the application of a particular state to a system. State functions frequently
call out to one or more execution modules to perform a given task. State files are written in both YAML and Jinja,
and use the .sls file extension.
The result of an assessment is the result of running the state file in test=True mode. If the result shows that
applying the state would have caused a change, the host is considered non-compliant. If applying the state would
not result in a change, the host is considered compliant.
For more on Salt States, see the Salt documentation.
20.3.3 Custom content library files
After building your custom content library, your directory includes the _dist directory, which contains the fol-
lowing additional files:
• digest.json - contains hashes and other information about the content
• secops_custom.tar.gz - gzip tar file ready for ingestion. This is suitable for upload through Enterprise
Console. For more on content ingestion, see https://enterprise.saltstack.com/.
• secops_custom.txt - base64 encoded version of secops_custom.tar.gz. This is useful when mak-
ing API calls
• secops_custom_YYYY-MM-DDTHH:MM:SS.SSSSSS...tar.gz - an identical copy of
secops_custom.tar.gz, preferred for upload through Enterprise Console because of its descrip-
tive filename, which includes the creation date and tarball UUID
20.4 See also
• SecOps Compliance
• Sec API interface
20.4. See also 107


CHAPTER
TWENTYONE
SECOPS VULNERABILITY
Note: SecOps Vulnerability is a SaltStack Enterprise add-on that provides automated vulnerability scanning and
remediation for your infrastructure.
A SecOps Vulnerability license is required.
21.1 Overview
SecOps Vulnerability is a vulnerability remediation solution. It allows Security and IT teams to work together to as-
sess the vulnerability status of your systems against the latest Common Vulnerabilities and Exposures (CVE) entries,
detect vulnerabilities, and remediate them. You can optionally exempt certain advisories or assets, to customize your
vulnerability management strategy around other existing security controls.
SecOps Vulnerability provides various vulnerability reporting options. It includes a quick, printable dashboard view
to help assess your vulnerability trend over time. For more on the dashboard, see Vulnerability dashboard. Following
a scan, you can access a downloadable list of all detected vulnerabilities, along with their corresponding advisory
name, severity, vulnerability score, and affected assets. For more on assessment results, see Assessment results.
As a SaltStack Enterprise add-on, SecOps Vulnerability goes beyond assessment, and takes advantage of Salt to
actively remediate vulnerabilities while also giving you full control over what to remediate and when.
21.2 How to use SecOps Vulnerability
To take advantage of SecOps Vulnerability, first define a security policy, scan your systems against it, and remediate
detected vulnerabilities as needed. You can optionally exempt certain advisories or assets, to customize the policy
around other existing security controls.
Note: This section describes how to use SecOps Vulnerability in the Enterprise Console. However, you can also use
it through the Enterprise API. See the Vman API interface, or contact an administrator for assistance.
21.2.1 Viewing your vulnerability dashboard
• Go to SecOps > Vulnerability.

The Vulnerability workspace shows an overview of your vulnerability activity. This is useful for sharing status
with others, and assessing your vulnerability management strategy over time.
109
Understanding the dashboard
For a vulnerability dashboard reference, see Vulnerability dashboard.
Printing your vulnerability dashboard
1. Go to SecOps > Vulnerability.

2. In your web browser menu, select Print.
You can save the vulnerability dashboard in PDF format.
21.2.2 Creating a policy
Note: Before creating your first policy, you need access to the vulnerability library. See Updating the vulnerability
library.

2. Click Create policy.
3. Enter a policy name and select the target you want to assess.
A target is the group of assets (referred to as Minions) your policy will apply to. For more on minions and
targets, or to create a new target, see Minions and targets.
Note: Scanning a large number of minions might result in long processing times. This could also delay other
processes, such as jobs running, in SaltStack Enterprise. Make sure to account for extra time required to run
large assessments.
4. To save the policy and define an assessment schedule, click Next step.
Note: You can also save and exit without defining a schedule. Click Save.
5. In the Schedule tab, define schedule frequency and click Save. For more on defining schedule settings, see
Schedules_.
Editing a policy
1. Go to SecOps > Vulnerability and select the policy you want to edit.
2. In the policy screen, click Edit policy in the upper-right corner.
3. Edit the policy as needed and click Save.
Updating the vulnerability library
1. In the upper-right corner of the Enterprise Console, click the Menu .
110 Chapter 21. SecOps Vulnerability

2. Go to System administration > SecOps.

3. Under Vulnerability, click Check for updates.
21.2.3 Running a vulnerability scan
Note: After initial installation, SaltStack Enterprise takes about 15-20 minutes to ingest vulnerability content. For
best results, wait at least 20 minutes after installing SaltStack Enterprise before you run your first vulnerability scan.

2. Select a policy.
Note: You can also run a scan from the Vulnerability workspace by selecting one or more policies and clicking
Run assessment.
3. In the policy home page, click Run assessment, then click Run assessment in the confirmation dialog.
SecOps Compliance begins to scan your systems against the latest CVE entries.
Note: During the assessment, no changes are made to any of your systems. You will have the ability to
remediate any issues later. See Remediating all vulnerabilities.
Tracking status

2. Select a policy.
3. In the policy home page, go to the Activity tab to see a list of completed or in-progress scans and remediations.
The initial status displays as Queued when you first run an assessment or remediation. This updates to Partial
while the activity is in progress, and changes to Completed once all minions have returned. You might need
to refresh your web browser to see status changes.
For more on activity statuses, see Activity status.
21.2.4 Viewing assessment results
1. Go to SecOps > Vulnerability and select a policy to view the latest assessment results.
The policy home page includes a list of advisories returned from the most recent assessment. For an assessment
results reference, see Assessment results. For more on running assessments, see Running a vulnerability scan.
2. Select the Minions tab to view assessment results sorted by node.
Downloading the assessment report
1. Go to SecOps > Vulnerability and select a policy to view the latest assessment results.
2. In the policy home page, go to the Report tab and click Download.
21.2. How to use SecOps Vulnerability 111

3. In the resulting dropdown, select JSON.

Your web browser begins downloading the report.
Note: You can also view and print your vulnerability dashboard in the Vulnerability home page. See Viewing
your vulnerability dashboard.
21.2.5 Remediating all Vulnerabilities
Note: When you run Remediate all, SecOps Compliance remediates all advisories on all minions in your policy,
which may result in long processing times. A best practice is to remediate by advisory or by minion to reduce
processing times.

2. Select the policy you want to remediate.
3. In the upper right of the policy home page, click Remediate all.
4. Click Remediate all in the confirmation dialog.
You can track the status of your remediation in the policy’s Activity tab. See Tracking status.
Note: Any exempted checks or minions are not remediated when you run Remediate all. See Adding
exemptions.
Remediating by advisory
1. Go to SecOps > Vulnerability and select a policy.

2. In the policy home page, select all advisories you want to remediate.
You can sort columns by clicking the column name. For example, you might sort advisories by severity to
choose which ones to remediate.
For more on running assessments, see Running a vulnerability scan.
3. Click Remediate.
Remediating by minion

2. In the policy home page, go to the Minions tab and select a minion.
3. Select all advisories you want to remediate for the active minion.
4. Click Remediate.

21.2.6 Adding exemptions

2. In the policy home page, select all advisories you want to exempt from remediation, and click Add exemption.
3. In the confirmation dialog, enter the reason for exemption, such as any mitigations in place, and click Add
exemption.
Adding exemptions by minion

2. In the policy home page, go to the Minions tab.
3. Select the minions you want to exempt from remediation.
later if needed.
Removing an exemption

2. In the policy home page, go to the Exemptions tab.
3. Scroll up and down the page to view a list of all exemptions. Each exemption includes the exemption reason,
and IDs of all advisories and minions the exemption applies to.
4. Click Remove exemption.
5. In the confirmation dialog, click Remove exemption.
21.2.7 Defining SecOps Vulnerability permissions
• Go to the Roles editor to modify SecOps Compliance permissions. For more on SaltStack Enterprise roles and
permissions, see Roles and Permissions.
21.3 Reference
21.3.1 Vulnerability policies
Vulnerability policies are collections of advisories, and specifications for which nodes each advisory applies to, in
SecOps Vulnerability. Policies can also include schedules, as well as specifications for handling exemptions.
Each component of a vulnerability policy is described in more detail below.
21.3. Reference 113

Target
A target is the group of minions, masters, or a single master that a job’s Salt command applies to. When you choose
a target in SecOps Vulnerability, you define the group of assets (referred to as Minions) your policy will apply to.
You can choose an existing target or create a new one. For more on targets, see Minions and targets.
Schedule
Note: In the schedule editor, the terms “Job” and “Assessment” are used interchangeably. When you define a
schedule for the policy, you are scheduling the assessment only - not the remediation.
Note: When defining an assessment schedule, you can choose from the additional Not Scheduled (on demand)
option. If you select this option, you choose to run only single assessments as needed, and no schedule is defined.
21.3.2 Activity status
In your policy home page, the Activity tab shows a list of completed or in-progress assessments and remediations.
It includes the following statuses.
finished running.
the requested tasks. The Salt Master is a central node used to issue commands to minions.
You can track all activity in SaltStack Enterprise, including assessments and remediations, in the SaltStack Enterprise
main Activity workspace. See Activity.
21.3.3 Vulnerability dashboard
Your vulnerability dashboard shows an overview of your vulnerability status. It includes various metrics, as well as
a list of known vulnerabilities and details about each.

The dashboard is useful for reporting your current vulnerability status. You can share the dashboard by linking to
the page URL, or by printing a PDF copy. See Viewing your vulnerability dashboard.
The dashboard includes the following metrics:
Metric Description
Vulnerability Summary The number of assets currently affected by vulnerabilities of different severity levels,
ranging from Critical to None.
Remediations The total number of vulnerabilities remediated through SecOps Vulnerability, sorted
by severity.
Vulnerability Trend Graph showing your vulnerability status over the last 30 days.
Top Advisories List of the most frequently-discovered vulnerabilities across your systems.
21.3.4 Assessment results
SecOps Vulnerability assessment results display in your policy home page. The page includes a list of advisories
with the following information fields:
Note: SecOps Vulnerability allows you to download assessment results in JSON. See Downloading the assessment
report.
Field Description
Severity Severity rating ranging from Critical to None. The severity rating is useful for prior-
itizing remediations.
Advisory title Official advisory title recognized by CVE. Click the advisory title to view its details.
CVE Common Vulnerabilities and Exposures, a list of common identifiers for publicly
known cybersecurity vulnerabilities.
Packages affected List of any system packages affected by the advisory
CVSS v3.0 Vulnerability rating according to the Common Vulnerability Scoring System version
3. This might not display for certain advisories as not all advisories have not been
scored yet.
CVSS v2.0 Vulnerability rating according to the Common Vulnerability Scoring System version
2
Minions Assets affected by the advisory. Minions are nodes running the Salt Minion service,
which can listen to commands from a master and perform the requested tasks. For
more on minions, see Minions and targets.
21.4 See also

• Activity
• Vman API interface
21.4. See also 115


CHAPTER
TWENTYTWO
SECOPS ARCHITECTURE
Note: SecOps Compliance is an add-on to SaltStack Enterprise that manages the security compliance posture
for all the systems in your environment. SecOps Vulnerability is an add-on to SaltStack Enterprise that manages
vulnerabilities on all the systems in your environment.
A license is required to use SecOps Compliance or SecOps Vulnerability.
22.1 Overview
The following diagram lists the primary components of SaltStack Enterprise and SecOps, along with the integration
points between each.
SecOps Compliance is an add-on to SaltStack Enterprise that manages the security compliance posture for all the
systems in your environment. For more on SecOps Compliance, see SecOps Compliance. SecOps Vulnerability is an
add-on to SaltStack Enterprise that manages vulnerabilities on all the systems in your environment. For more on
SecOps Vulnerability is an add-on to SaltStack Enterprise that manages vulnerabilities on all the systems in your
environment., see SecOps Vulnerability. For a description of each of SaltStack Enterprise’s primary components, see
Architecture.
22.1.1 SecOps content libraries
In contrast with a standalone SaltStack Enterprise architecture, the SecOps add-ons includes regularly-updated con-
tent, as well as SecOps Compliance custom content. Together, SecOps includes the following content libraries:
117
Compliance Content - SaltStack Built-in security content for SecOps Compliance

Compliance Content - Custom Custom checks and benchmarks defined and uploaded by your organization
Vulnerability Content Built-in advisories for SecOps Vulnerability
SaltStack content libraries update regularly as security standards change, and are downloaded from https://
enterprise.saltstack.com.
You can configure SaltStack content to download automatically as updates become available, or you can download
content manually. For more on configuring SecOps, go to > SaltStack SecOps configuration.
For more on creating custom content, see secops-custom-content.
22.2 See also
• SecOps Compliance
• secops-custom-content
• SecOps Vulnerability
• SaltStack Enterprise architecture
• RPC Endpoint Documentation
118 Chapter 22. SecOps Architecture

CHAPTER
TWENTYTHREE
SALTSTACK ENTERPRISE CONFIGURATION
23.1 Overview
SaltStack Enterprise configuration files are used during initial setup to define fundamental settings to allow the
Enterprise API to communicate with the database and connected Salt Masters.
23.2 How to configure SaltStack Enterprise
You can customize your SaltStack Enterprise deployment during initial setup, or any time you want to improve
performance, by modifying your Enterprise API or Salt Master configuration files.
23.2.1 Generating default configuration files
You can generate the default configuration files as needed. For example, you might find it useful to regenerate these
files when upgrading SaltStack Enterprise to take advantage of the latest features. For more on generating default
configuration files, see Configuration file example and Master Plugin.
23.3 Reference
SaltStack Enterprise configuration is divided into the following sections:

• Enterprise API
• Network configuration
• Salt Masters and the Salt Master plug-in
Note: For Salt Master configuration see Master Plugin.
23.3.1 Enterprise API
Enterprise API settings are in the /etc/raas/raas configuration file. The following is a subset of frequently-used
configuration settings. For a full raas configuration reference, see Configuration file example.
119
Required settings
customer_id Your customer ID, or sample UUID.

sql username, password, host, and port can be configured to match your database configuration. For more on
storing credentials securely, see the Securing credentials in your SaltStack Enterprise configuration Knowledge
Base article.
Other important settings
tls_crt Path to the crt file for encrypted communication. If this certificate is self-signed and should not be validated
using a known CA, be sure to set the sseapi_validate_cert option to False in the Salt Master config.
tls_key Certificate key file.
port Port that is used for connections from Enterprise Console and Salt Masters.
audit Include Enterprise API information in the Debug report for administrator accounts. If valid_logins is
set to True, this information is also included in bug reports that are generated by non-admin users. See
Troubleshooting.
raas_presence_expiration Seconds of inactivity before a minion is considered not present. Default is 3600 seconds
(one hour).
For a full reference of configuration options, see Configuration file example.
23.3.2 Network configuration
Communication with Enterprise API uses REST calls over HTTP(s) on standard web ports (80 or 443). Connections
to Enterprise API are initiated by the Enterprise Console or by the Salt Master, so incoming ports do not need to be
configured on those systems.
23.4 See also
• Architecture
• Enterprise API (eAPI) RPC Endpoint Documentation
• Configuration file example
120 Chapter 23. SaltStack Enterprise Configuration

CHAPTER
TWENTYFOUR
MASTER PLUGIN
24.1 Overview
The Salt Master plugin enables your masters to communicate with SaltStack Enterprise. The Salt Master is a central
node used to issue commands to minions. This article describes how to install, authenticate, and configure the master
plugin.
24.2 How to configure the Master Plugin
24.2.1 Installing the master plugin
1. Download the Salt Master plugin Egg file. See https://enterprise.saltstack.com/.

2. Install the plugin (requires Python setuptools).
sudo easy_install-2.7 SSEAPE-X.X.X+X-py2.7.egg
3. Verify the /etc/salt/master.d directory exists. If it doesn’t, create it.

4. Generate the master configuration settings.
sseapi-config --all > /etc/salt/master.d/raas.conf
5. Edit the generated raas.conf file to update or comment out the following values: - id - sseapi_server
For more on other options in raas.conf, see Reference.
6. Restart the Salt Master.
sudo systemctl restart salt-master
24.2.2 Setting up public key authentication
During the master startup (unless using password authentication), the master will request a public key from raas.
Then raas will generate a public key file and the master will download the public key. At this point, you will need
to accept the master key in the Enterprise Console.
To accept the key:
1. Go to System Administration > Master Keys in the Enterprise Console.
2. Click Pending.
121
3. Verify the finger print matches the finger print in your master log files.
4. Select the master key and click Accept.
5. Accept keys for all masters.
Note: The master will continue to run but communication with raas will fail until the key is accepted. Also, the
master will react slowly as it continually tries to contact raas.
If you delete the public key, the master will need to request a new public key from raas. When a public key is
invalid or absent, the master will request a new key every five minutes until it is accepted and validated.
Public keys are rotated automatically based on the sseapi_key_rotation setting, which is set to 24 hours by
default. To rotate the key manually, delete the key file, restart the master, and accept the key by following the
previous steps. For more on key states, see Key states.
To allow masters to communicate with minions, make sure to accept minion keys on all masters. For more on minion
keys, see Minion Keys.
By default, a local user is associated with each Salt Master key used for authentication. For more on local users, see
Local Users.
24.2.3 Setting up username authentication (deprecated)
Note: This method is deprecated and will be removed in a future release.
1. Open /etc/salt/master.d/raas.conf.
2. Set sseapi_username and sseapi_password to authenticate using a username and password set, for
example:
sseapi_username: username
sseapi_password: password
24.2.4 Generating a default Master Plugin configuration
files when upgrading SaltStack Enterprise to take advantage of the latest features.
To generate the default sseape (master plugin) configuration file, run this command on a master with the plugin
installed:
sseapi-config --default-config >/path/to/default-sseape-cfg.conf
Note: The syntax is slightly different from generating the default RaaS configuration file. In this case, you’ll send
the output to stdout and then redirect it > to a file path that indicates where the generated file should be saved.
For information about generating the default RaaS configuration file, see Configuration file example.
122 Chapter 24. Master Plugin

24.3 Reference
Settings that enable each Salt Master to connect to Enterprise API are in the /etc/salt/master.d/raas.conf
configuration file. This file is initially created during the Enterprise API master plug-in installation.
Warning: Salt master settings in the raas.conf file take precedence over existing settings in /etc/salt/
master. If you have customized the FILESERVER_BACKEND or EXT_PILLAR settings in /etc/salt/
master, you need to manually merge these settings so that they appear in one file only. You can optionally
re-order the backends to change precedence.
• id: Master ID, autogenerated if not set

• sseapi_server: SSEAPI Server Address
• engines: Salt engines required: sseapi, jobcompletion
• fileserver_backend: file server backends, recommended sseapi and roots
• ext_pillar: external pillar sources, recommended sseapi
• master_job_cache: sseapi or sse_pgjsonb
• event_return: sseapi or sse_pgjsonb
• sseapi_force_restfull: when True use restful HTTP calls instead of a continuous websocket connection
• sseapi_poll_interval: how frequently in seconds to poll for new data. Default 30 seconds
• sseapi_update_interval: how frequently in seconds to update from file server. Default 60 seconds
• sseapi_connect_timeout: timeout for initial connection in seconds. Default 5 seconds.
• sseapi_request_timeout: timeout for entire request in seconds. Default 15 seconds.
• sseapi_key_rotation: key rotation in seconds (default 24 hours)
• sseapi_pubkey_path: path to public key file
• sseapi_max_message_size: max websocket message size. Default 10Mib 10*1024*1024
• sseapi_websocket_ping_interval: send a websocket ping every 15 seconds
• sseapi_websocket_ping_timeout: # If after 10 minutes there’s no response, close the connection to the
server
24.3.1 SSL settings
• sseapi_ssl_ca: path to a CA file or directory

• sseapi_ssl_key: path to the certificate’s private key
• sseapi_ssl_cert: path to the certificate
• sseapi_ssl_validate_cert: whether to validate or not the certificate that RaaS uses. Defaults to True.
24.3.2 PG JSON Return settings
• returner.sse_pgjsonb.host: database hostname

• returner.sse_pgjsonb.user: database username
24.3. Reference 123

• returner.sse_pgjsonb.pass: database password

• returner.sse_pgjsonb.db: database name
• returner.sse_pgjsonb.port: database port
24.3.3 Directories settings
After initial configuration generation be careful changing these settings. Modules will be copied into these directories
from the installation process. However, adding extra paths will not have an adverse effect.
• beacons_dirs: beacons External Modules Path(s)
• engines_dirs: engines External Modules Path(s)
• fileserver_dirs: fileserver External Modules Path(s)
• pillar_dirs: pillar External Modules Path(s)
• returner_dirs: returner External Modules Path(s)
• roster_dirs: roster External Modules Path(s)
• runner_dirs: runner External Modules Path(s)
• module_dirs: Salt External Modules Path(s)
• proxy_dirs: proxy External Modules Path(s)
• metaproxy_dirs: metaproxy External Modules Path(s)
• states_dirs: states External Modules Paths(s)
24.3.4 Key states
SaltStack Enterprise displays master keys with one of the following statuses.
Accepted Key was accepted and the master can communicate with the Enterprise API.
Pending Key is not accepted or denied. In this state, connections are not accepted from the Enterprise API.
from the master.
For more on managing master keys, see Setting up public key authentication.
24.4 See also
• SaltStack Enterprise Configuration

• Architecture
• Minion Keys
• Local Users
124 Chapter 24. Master Plugin

CHAPTER
TWENTYFIVE
CONFIGURATION FILE EXAMPLE
This topic includes a sample /etc/raas/raas configuration file listing all available configuration settings con-
figured with default options.
For more on configuring SaltStack Enterprise, see SaltStack Enterprise Configuration.
25.1 Generating a default RaaS configuration file
files when upgrading SaltStack Enterprise to take advantage of the latest features.
To generate the default RaaS configuration file, run this command on the RaaS server:
raas genconfig /path/to/default-raas-cfg.conf
Note: The last argument of the above command indicates where to save the generated file. You should not use the
file path /etc/raas/raas, as this will overwrite the current RaaS configuration file. Only use this file path if you
have no need to preserve an existing current RaaS configuration file.
For information about generating a default Master Plugin configuration file, see Master Plugin.
25.2 Example Enterprise API configuration file
/etc/raas/raas
# RaaS Default Configuration
# Elastic APM settings

apm_elastic:
service_name: # Elastic APM Service Name
secret_token: # Elastic APM Secret Token
server_url: # Elastic APM Server URL
environment: production
# audit tracking settings

audit:
enabled: false
valid_logins: false
auth: true
rpc: true
125
system: true
tasks: false
rpc_max_payload: 100
# authenication backends
authers:
ldap:
log_detail: ERROR
ssl: {}
# SAML, OAuth, or OpendID authenication backends config

auth_backends:
backends: []
settings:
login_url: /
login_redirect_url: --auth-done--
# configuration settings for background workers

background_workers:
combined_process: true # run background and web workers together
concurrency: 0 # number of worker processes (0 = auto calc
˓→one per core up to max)
max_tasks: 100000 # worker recycles after max tasks

max_memory: 0 # in kB, 0=auto, None=unlimited
broker: redis
backend: redis
result_expires: 60 # in seconds, how long results are stored in
˓→Redis
prefetch_multiplier: 4 # How many messages to prefetch at a time

˓→multiplied by the number of concurrent processes.
without_heartbeat: false # When true, Don't send event heartbeats.

˓→Reduces Redis usage.
without_mingle: false # When true, Don't synchronize with other

˓→workers at start-up. Reduces worker startup up time.
without_gossip: false # When true, Don't subscribe to other workers

˓→events. Reduces redis usage.
# how often to run cache jobs (in seconds)

cache_cycle: 30
# path to RaaS cache directory

cachedir: /var/lib/raas/cache
# how often to run clean up jobs (in seconds)

clean_up_cycle: 900
# path to config directory (can be passed multiple times, order is respected)

config_dir: []
# read files in config_dir subdirs recursively

config_recurse: false
# HTTP Cookie settings

cookie:
name: raas-session
expires: 43200
# for use with the webpack dev server only, Add the Access-Control-Allow-Origin: *
˓→header
126 Chapter 25. Configuration file example

cors_header_for_webpack: false
# Your customer ID
customer_id: 43cab1f4-de60-4ab1-85b5-1d883c5c5d09
# directory to serve files from

directory_root: /srv/raas
# enable (true) or disable (false) grains indexing.

enable_grains_indexing: true
# enable (true) or disable (false) cmd details in get_cmds API call. Should be
˓→disabled when return counts are large.
enable_cmd_details: true
# Limit returns passed to UI so they don't crash the browser. 0 is unlimited.

˓→Recommended to set as a mutliple of 50.
cmd_returns_max: 0
# path to extension module directory

extension_modules: /var/lib/raas/cache/ext_mods
# the address to bind to

interface: 0.0.0.0
# time to check unresponsive jobs (in minutes)

job_unresponsive_check: 5
# time to stop checking unresponsive jobs (in minutes)

job_unresponsive_check_stop: 2880
# JSON Web Token settings

jwt:
expires: 3600 # token expiration in seconds
login_expires: 60 # external authenication, login token
˓→expiration in seconds
algorithm: HS256
max_logins: 100
# date and time format for console logs

log_datefmt: '%H:%M:%S'
# date and time format for logfile logs

log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'
# path to log file

log_file: /var/log/raas/raas
# loglevel for logfile logs, options: all, garbage, trace, debug, profile, info,
˓→warning, error, critical, quiet
log_file_loglevel: error
# log format for console logs

log_fmt_console: '[%(levelname)-8s] %(message)s'
# log format for logfile logs

log_fmt_logfile: '%(asctime)s,%(msecs)03.0f [%(name)-17s][%(levelname)-8s:%(lineno)-
˓→4d][%(processName)s:%(process)d]
25.2. Example Enterprise API configuration file 127

%(message)s'
# loglevels for specific python modules

log_granular_levels: {}
# options: all, garbage, trace, debug, profile, info, warning, error, critical, quiet
log_level: error
# master RSA private key size

master_key_size: 2048
# expiration timeout for pending master keys in seconds

master_pending_key_expiration: 7200
# max number of unresponsive master checks

master_unresponsive_check_limit: 2
# template used to generate master users

master_username_template: master_{}
# 0=off, max seconds to lock when adding minion keys and cache. This throttles insert
˓→of minions into the database.
minion_onboarding_throttle: 0
# max number of auto calculated processes per type. example: 8 max web, 8 max
˓→background workers
max_processes: 8
newrelic_config_file: /etc/raas/newrelic.ini
newrelic_enabled: false
# number of web server processes (0 = auto calc one per core up to max)
num_processes: 0
# number of password attempts to start blocking

password_attempts: 50
# number of seconds to sleep following a failed attempt

password_sleep: 30
# path to RaaS process ID file

pidfile: /var/lib/raas/run/raas.pid
# path to directory for RaaS PKI keys

pki_dir: /etc/raas/pki
# port to bind to
port: 8080
# delta proxy monitoring options

proxy:
monitored: false
monitor_interval: 90
rebalance_interval: 120
tgt: deltaproxy*
tgt_type: glob

# To use the the environment variable REDIS_URL, set ùrl: ENV`.

redis:
url: redis://localhost:6379 # Redis URL without '/{database_number}' at
˓→the end
broker_db: '0' # queue database number

result_db: '1' # result storage database number
cache_db: '2' # cache database number
ssl: {}
# multiplier used to calculate retry timing on connection failures

retry_timeout_multiplier: 3
root_dir: /
# how often to check for scheduled jobs (in seconds)

schedule_cycle: 10
# how many future schedules are calculated per cycle

scheduler_max_futures_per_cycle: 500
# how many weeks ahead schedules are calculated out to

scheduler_max_futures_weeks_ahead: 12
# SecOps settings
sec:
stats_snapshot_interval: 3600 # Interval in seconds between when stats for
˓→Secops will be gathered (ENV Var: SSE_SEC_STATS_SNAPSHOT_INTERVAL)
username: secops # Username used to log in to enterprise.

˓→saltstack.com to get content (ENV Var: SSE_SEC_USERNAME)
content_url: https://enterprise.saltstack.com/secops_downloads # URL from which

˓→SaltStack Secops content will be downloaded. (ENV Var: SSE_SEC_CONTENT_URL)
ingest_saltstack_override: true # If True, existing SaltStack content will be

˓→updated otherwise the change will be rejected. (ENV Var: SSE_SEC_INGEST_SALTSTACK_
˓→OVERRIDE)
ingest_custom_override: true # If True, existing Custom content will be

˓→updated otherwise the change will be rejected. (ENV Var: SSE_SEC_INGEST_CUSTOM_
˓→OVERRIDE)
locke_dir: locke # Location where SaltStack content in expanded

˓→before ingestion. If the path is relative (no leading slash), then it is relative to
˓→the RAAS cache dir (ENV Var: SSE_SEC_LOCKE_DIR)
post_ingest_cleanup: true # If True, post ingestion the contents of the

˓→locke_dir will be cleaned out. (ENV Var: SSE_SEC_POST_INGEST_CLEANUP)
download_enabled: true # If True, SaltStack content downloading is

˓→enabled. (should be False for air gapped systems) (ENV Var: SSE_SEC_DOWNLOAD_
˓→ENABLED)
download_frequency: 86400 # The frequency in seconds of automated

˓→SaltStack Secops content downloads and ingestion. (ENV Var: SSE_SEC_DOWNLOAD_
˓→FREQUENCY)
compile_stats_interval: 10 # Interval in seconds between times that the

˓→compile stats will be gathered. (ENV Var: SSE_SEC_COMPILE_STATS_INTERVAL)
archive_interval: 300 # The interval in seconds between attempts to

˓→archive old assessment/remediation results (ENV Var: SSE_SEC_ARCHIVE_INTERVAL)
old_policy_file_lifespan: 2 # The lifespan of old lock policy files in

˓→days that will remain in the RAAS file system
delete_old_policy_files_interval: 86400 # The interval in seconds between times that

˓→theold lock policy files in the RAAS file system will be deleted
ingest_on_boot: true # If True, SaltStack Secops content will be

˓→downloaded and ingested soon after RAAS boot (ENV Var: SSE_SEC_INGEST_ON_BOOT)

content_lock_timeout: 60 # When multiple RAAS heads are deployed, the

˓→SaltStack SecOps content download and ingestion is serialized so only one RAAS head
˓→at a time will attempt it. This is the value for the redis lock timeout. (ENV Var:
˓→SSE_SEC_CONTENT_LOCK_TIMEOUT)
content_lock_block_timeout: 120 # This is the maximum time a RAAS head will

˓→block on a lock to perform a SaltStack SecOps download and ingestion. (ENV Var: SSE_
˓→SEC_CONTENT_LOCK_BLOCK_TIMEOUT)
# Sentry DSN to report errors (sensitive data is obfuscated)

sentry_dsn:
# path to RaaS directory for socket files

sock_dir: /var/lib/raas/sock
# for development only, always serve the session cookie regardless of the request
˓→being http or https
spa_serve_cookie_always: false
# REQUIRED: fill in your database info

# - SQLAlchemy options - http://docs.sqlalchemy.org/en/rel_1_0/dialects/index.html
# - To use the the environment variable DATABASE_URL, set ùrl: ENV`. For example:
# $ export DATABASE_URL=postgres://user:secret@localhost:5432/raas_db_name
# - To store database credentials in an encrypted file, run "raas save_creds"
# after installation.
# - It is possible, but not recommended practice, to specify database credentials
# in plaintext in this section as ùsername: user` and `password: secret`.
sql:
dialect: postgresql
driver: psycopg2
host:
port:
pool_size: 10
pool_timeout: 10
pool_recycle: 3600
# strict transport security header enabled (aka HSTS, HTTPS only)

strict_transport_security_header_enabled: true
# cross-site request forgery cookie enabled

tornado_xsrf_cookies_enabled: true
# check the running environment prior to starting services

verify_env: true
# Vulnerability Management settings

vman:
vman_dir: vman # Location where SaltStack content in expanded
˓→before ingestion. If the path is relative (no leading slash), then it is relative to
˓→the RAAS cache dir (ENV Var: SSE_VMAN_DIR)
download_enabled: true # If True, SaltStack content downloading is

˓→enabled. (should be False for air gapped systems) (ENV Var: SSE_VMAN_DOWNLOAD_
˓→ENABLED)
download_frequency: 86400 # The frequency in seconds of automated

˓→SaltStack Vulnerability Management content downloads and ingestion. (ENV Var: SSE_
˓→VMAN_DOWNLOAD_FREQUENCY)
username: vman # Username used to log in to enterprise.

˓→saltstack.com to get content (ENV Var: SSE_VMAN_USERNAME)
content_url: https://enterprise.saltstack.com/vman_downloads # URL from which

˓→SaltStack Vulnerability Management content will be downloaded. (ENV Var: SSE_VMAN_
˓→CONTENT_URL)

ingest_on_boot: true # If True, SaltStack Vulnerability Management

˓→content will be downloaded and ingested soon after RAAS boot (ENV Var: SSE_VMAN_
˓→INGEST_ON_BOOT)
compile_stats_interval: 60 # Interval in seconds between times that the

˓→compile stats will be gathered. (ENV Var: SSE_VMAN_COMPILE_STATS_INTERVAL)
stats_snapshot_interval: 3600 # Interval in seconds between when stats for

˓→VMan will be gathered (ENV Var: SSE_VMAN_STATS_SNAPSHOT_INTERVAL)
old_policy_file_lifespan: 2 # The lifespan of old policy files in days

˓→that will remain in the RAAS file system
delete_old_policy_files_interval: 86400 # The interval in seconds between times that

˓→theold vman policy files in the RAAS file system will be deleted
# how long to wait while reading body (seconds), when None uses tornado default
webserver_body_timeout:
# maximum amount of data for body, when None uses tornado default
webserver_max_body_size:
# maximum amount of incoming data to buffer, when None uses tornado default
webserver_max_buffer_size:
# in kB, 0=auto
webserver_max_memory: 0
# in seconds, 0=disabled
webserver_max_time: 0
# max interval in seconds subscription updates can be sent

websocket_debounce: 5
# time in seconds to send ping over websocket to keep it open

websocket_ping_interval: 15
# timeout in seconds to wait for websocket ping

websocket_ping_timeout: 600
# in seconds, polling time for non-database listening subscriptions

websocket_polling: 15
25.2.1 See also
• SaltStack Enterprise Configuration


CHAPTER
TWENTYSIX
SAMPLES
26.1 Overview
SaltStack Enterprise provides several default targets and jobs along with supporting files and pillar data.
Sample job files and pillar data are placed in the sse Salt environment so they don’t interfere with files and pillar
data in the base environment. For more on environments in SaltStack Enterprise, see Environments.
A target is the group of minions, masters, or a single master that a job’s Salt command applies to. For more on
targets, see Minions and targets. Jobs are used to run remote execution tasks, apply states, and start Salt runners.
For more on jobs, see Jobs.
Files in SaltStack Enterprise are useful for configuring states you can then apply through jobs. Files are stored in the
file server. The file server is a location for storing both Salt-specific files, such as top files or state files, as well as files
that can be distributed to minions, such as system configuration files. For more on the file server, see File Server.
Pillars are structures of data defined on the Salt Master and passed through to one or more minions, using targets.
They allow confidential, targeted data to be securely sent only to the relevant minion. For more on pillars, see Pillars.
26.2 How to use SaltStack Enterprise samples
Samples are used to save time setting up your SaltStack Enterprise environment. With default jobs, you can take
advantage of predefined state files and pillar data to begin running frequently-used operations.
You might also refer to samples as a model for how different system elements are configured to work together as
you build your own workflows.
26.3 Reference
26.3.1 Default targets
SaltStack Enterprise includes a range of default target groups containing all minions of a given operating system.
The following default targets are defined by matching the os grain.
• CentOS
• Linux
• MacOS
• RedHat
133
• SUSE
• Ubuntu
• Windows
• Windows Servers
For more on targets, see Minions and targets.
26.3.2 Sample jobs
SaltStack Enterprise provides various state and remote execution jobs. Each is described in further detail below, with
a description of related files and pillars where applicable.
Enable Presence
Enables more accurate presence detection. Presence indicates if SaltStack Enterprise has received any job data from
the minion recently, within a defined interval. For more on presence, see presence.
Highstate
Runs a state.highstate on targeted Salt Minions. A highstate is a state module that applies all states configured
in the top.sls file. top.sls must be user-defined and is not included as a sample file. For more on states, see
Jobs.
Sample Apache
files sse/apache/init.sls
pillar None
Installs Apache. This state contains logic to determine the correct name of the Apache package based on the target
OS.
Sample Disk Usage
Runs the disk.usage command on targeted Salt Minions.
Sample DokuWiki
files sse/dokuwiki/init.sls, sse/dokuwiki/files/*

includes PHP, Apache
pillar customization
• dokuwiki_url: sets the URL path where the wiki should appear, default wiki.
• wiki_title: sets the wiki title, default My Wiki.
134 Chapter 26. Samples

Sample HTOP install
files sse/htop/init.sls
pillar None
Installs HTOP.
Sample HTOP remove
files sse/htop/remove.sls
pillar None
Removes HTOP.
Sample LAMP stack
files sse/LAMP/init.sls
includes mySQL, PHP, Apache
pillar customization
• db_user: default dbuser.
• db_name: default dbname.
• db_pass: default password.
• db_host: default localhost.
Installs Apache, mySQL, and PHP.
Sample mySQL
files sse/mysql/init.sls
pillar None
Installs mySQL.
Sample PHP
files sse/php/init.sls
pillar None
Installs PHP.
Sample refresh pillar
Refreshes the Salt pillar on targeted Salt Minions. Run this after assigning pillar data to Salt Minions.
26.3. Reference 135

Sample WordPress
files sse/wordpress/init.sls
pillar None
Installs WordPress.
test.ping
Runs the test.ping command on targeted Salt Minions.
26.4 See also

• Jobs
• File Server
• Pillars
136 Chapter 26. Samples

CHAPTER
TWENTYSEVEN
SECURITY GUIDELINES
27.1 Overview
This page contains guidelines you can use to increase security within your SaltStack Enterprise environment.
Note: This does not cover SaltStack SecOps. For more on SecOps, see either of the following:
• SecOps Compliance - SecOps Compliance is an add-on to SaltStack Enterprise that manages the security com-
pliance posture for all the systems in your environment.
• SecOps Vulnerability - SecOps Vulnerability is an add-on to SaltStack Enterprise that manages vulnerabilities
on all the systems in your environment.
A license is required to access SecOps.
27.2 Reference
27.2.1 Automatic logout if inactive
You can set automatic logout as low as 1 minute, and up to 60 minutes. This is set to 30 minutes by default. For more
on modifying this and other preferences, see Enterprise Console.
27.2.2 Permissions
Make sure to limit access to the following tasks. For more on defining permissions, see Roles and Permissions.
Job create and edit
Limit user access to creating and editing jobs. These privileges enable a user to run any command in the system.
Together with target create and edit permission, they enable a user to run any command on any minion.
Target create and edit
Limit user access to creating and editing targets. These privileges, along with Job create and edit permission, enable
a user to run available jobs on any Salt Minion in the system.
137
Role create and edit
Limit user access to creating and editing roles. These privileges enable a user to assign themselves any privilege in
the system.
27.2.3 Encrypted credentials
Enterprise API Access Credentials
Connect masters to the Enterprise API through public key authentication (default), rather than through username
authentication. For more on setting up public key authentication, see Master Plugin.
Database credentials
Store database credentials for both PostgreSQL and Redis in an encrypted file, rather than in plain text. For more on
credential storage, see the SaltStack Knowledge Base.
27.3 See also
• Master Plugin
138 Chapter 27. Security Guidelines

CHAPTER
TWENTYEIGHT
ENTERPRISE API (EAPI) RPC ENDPOINT DOCUMENTATION
28.1 Introduction
In this document, SSE refers to the application server that SaltStack Enterprise clients connect to. These clients
include the user interface component of SaltStack Enterprise, properly configured salt masters, and other users of
the SaltStack Enterprise API. The application server is also known as the eAPI server.
The SSE API is organized into modules (called “resources”) and functions (called “methods”). In the API call
test.echo(‘hello, world’), the resource is test and the method is echo(). Arguments can be passed to methods by
position or by keyword.
The SSE API can be accessed in two ways: via an RPC client that works over a WebSocket connection, and via an
HTTP (or HTTPS) bridge.
To connect to the API, set these options in client = SyncClient.connect():
• server
• username
• password
• config_name=’internal’ Change to authentication backend name if using LDAP
• force_restfull=False # False = use WebSockets True = use REST bridge
• connect_timeout=5 # Take at most 5 seconds to connect to server
• request_timeout=15 # Each request times out at 15 seconds
• ssl_ca=None
• ssl_key=None
• ssl_cert=None
• ssl_context=None
• ssl_validate_cert=True = Set to False if using self signed certs
Example:
from sseapiclient.tornado import SyncClient

client = SyncClient.connect('https://localhost', 'root', 'salt', ssl_
˓→validate_cert=False)
139
28.2 API syntax
client.api.<interface>.<method>(parameter=parameter_value)
Example:

client = SyncClient.connect('https://localhost', 'root', 'salt')
client.api.sec.content.download_and_ingest(auto_ingest=True)
28.3 Using the API with Curl
You can also use the Enterprise API with directly with HTTP and JSON. The following is an example of using the
API with curl. Note when xsrf is enabled you will need to obtain an xsrf cookie and token first. See HTTP Bridge
on how to obtain and use an xsrf token and cookie. When using the Python API client, this is done automatically by
default.
Example:
curl --user 'root:salt' --url 'https://localhost/rpc'

--data '{
"resource": "sec",
"method": "download_and_ingest",
"kwarg": {"auto_ingest": true}
}'
28.4 Permissions
You can assign permissions to a role or user in the Enterprise API using save_role(...) or save_user(...)
in the API AUTH interface. For more on roles and permissions in SaltStack Enterprise, see Roles and Permissions.
28.4.1 API Permission values
You can assign permissions to a role or user in the Enterprise API using save_role(...) or save_user(...)
in the API AUTH interface.
Permission value syntax
Permission values in the Enterprise API include a resource type and an action, based on the following syntax:
• resource-action
Some permission values include a qualifier as follows:
• resource-qualifier-action
For example, if you want to assign permission to run commands, you would use cmd-run. Whereas, to assign
permission to run wheel commands, you would use cmd-wheel-run.
Note: The above syntax does not apply to the Super user permission, whose API value is superuser.
140 Chapter 28. Enterprise API (eAPI) RPC Endpoint Documentation

API Permission values by resource
The following list includes all resource types and permitted actions.
For a detailed explanation of each resource type, and of permissions in SaltStack Enterprise, see Roles and Permissions.
Commands
• cmd-delete
• cmd-read
• cmd-run
• cmd-write
Runner commands
• cmd-runner-run
SSH commands
• cmd-ssh-delete
• cmd-ssh-read
• cmd-ssh-run
• cmd-ssh-write
Wheel commands
• cmd-wheel-run
Formulas
• formula-delete
• formula-read
• formula-write
Filesystem
• fs-delete
• fs-read
• fs-write
Groups
• group-delete
• group-read
• group-write
Jobs
• job-delete
• job-read
• job-run
• job-write
License
• license-read
28.4. Permissions 141

Master
• master-delete
• master-read
• master-write
Master configuration
• master-config-delete
• master-config-read
• master-config-write
Master filesystem
• master-fs-delete
• master-fs-read
• master-fs-write
Minions
• minion-delete
• minion-read
• minion-write
Pillar
• pillar-delete
• pillar-read
• pillar-write
Returners
• returner-delete
• returner-read
• returner-write
Roles
• role-delete
• role-read
• role-write
Schedules
• schedule-delete
• schedule-read
• schedule-write
Super user
• superuser
Target
• target-delete

• target-read
• target-write
• target-allminions-run
Users
• user-delete
• user-read
• user-write
28.5 Licensing
The SaltStack Enterprise web console displays notifications to warn when your license is close to expiring. As an
Enterprise API user, you must use the License interface to track license status and ensure it stays active. If your
license expires, the SaltStack Enterprise service stops. See License interface.
28.6 RPC over WebSockets
The programmatic RPC clients in the sseapiclient module work with Python version 2.7 and Python version 3.5
or later. The clients connect to SSE via HTTP or HTTPS, authenticate, then upgrade to a persistent WebSocket
connection, so that the overhead of establishing a connection and authenticating is incurred only once per session.
Using the RPC client also has the advantage of being somewhat easier to use than the HTTP bridge.
28.7 HTTP Bridge
The HTTP (or HTTPS) bridge accepts JSON payloads POSTed to an endpoint exposed by SSE, translates the payloads
into RPC calls, then returns the result as JSON. The endpoint supports cookie-based authentication so that authenti-
cation credentials need to be passed only once per session. The bridge also allows sending multiple calls in a single
payload.
If xsrf is enabled (default with state install) in the /etc/raas/raas.conf tornado_xsrf_cookies_enabled: True you will
need to provide the X-Xsrftoken: on the header of the rest call. The best way is to save a cookie with a get call then
use the cookie to provide the header token. This cookie is saved in the $HOME (users home) directory. The payload
is a dictionary.
Example curl call with xsrf header:
curl -k -c $HOME/eAPICookie.txt -u root:salt 'https://localhost/account/login

˓→' >/dev/null
curl -k -u root:salt -b $HOME/eAPICookie.txt -H 'X-Xsrftoken: '$(grep -w '_

˓→xsrf' $HOME/eAPICookie.txt | cut -f7)'' -X POST https://localhost/rpc -d'{
˓→"resource": "admin", "method": "trim_database", "kwarg": { "audit": 30,
˓→"events": "30", "jobs": "30", "test": "True" }}'
The samples assume:

• client=SyncClient.connect(<addr>,<user>, <pwd>)
• Default state based install of eAPI
• SSL enabled
28.5. Licensing 143

• Import of sseapiclient. Example:
28.8 RPC Endpoints
28.8.1 admin interface
Admin RPC endpoint
trim_database(…)
Returns Dict.
Trim records from various database tables. Returns number of records of each type that would be deleted from the
database. When test=True these records will not be deleted. If test is None or False this call will delete the
records as well.
Table 28.1: trim_database() parameters

audit Number of days of data from the audit trail tables to
retain.
events Number of days of data from the event tables to retain.
jobs Number of days of data from the jobs tables to retain.
schedule Number of days of schedule history to retain.
test When test=True no records will be deleted.
Returns
Dictionary with audit, events, jobs, and/or schedule keys, matching the arguments passed to the call. Each key is
associated with the number of corresponding records removed from the database, except jobs, which is a dictionary
containing the number of commands, minions-expected, returns, and jids entries that were deleted.
These results are also logged in the RaaS log at info level.
Example using the Python client

host = 'http://localhost'
user = 'root'
password = 'salt'
client = SyncClient.connect(host, user, password)
client.api.admin.trim_database(
audit=30, events=30, jobs=30, schedule=30, test=True)
Additional connect arguments: If you have a large dataset and you want to wait longer than 15 seconds (default
timeout) for the request. request_timeout=None
Needed sometimes if your SSL Certificate is self signed. ssl_validate_cert=False
Example response

RPCResponse(
warnings=[],
error=None,
riq=139727129350384,
ret={
"test": True,
"jobs": {
"commands": 5394,
"minions-expected": 231,
"returns": 4403,
"jids": 299
},
"events": 30,
"audit": 123,
"schedule": 48
}
)
28.8.2 api interface
RPC API Handler
discover(…)
Returns Dict.
Return the RPC resources, their methods and the methods documentation. The RPC client calls this method on each
connection and stores the result in the client object in _discovered_api.
param dict or list include filter document to only include listed sections
include: {‘<section-key>’: ‘<sub-section-key>’} or [‘<section1-key>’]

client = SyncClient.connect('http://localhost', 'root', 'salt')
client.api.api.discover()
client.api.api.discover(include=['constants'])
client.api.api.discover(include={'constants': ['permissions', 'command-states']})
get_versions(…)
Returns Dict.
Return information on various software components used by RaaS.

client.api.api.get_versions()
28.8. RPC Endpoints 145

RPCResponse(
riq=4,
ret={'python': '3.5.3 (default, Sep 14 2017, 22:58:41)',
'opts': {'sql': {'dialect': 'postgresql',
'host': 'localhost', 'pool_timeout': 10,
'driver': 'psycopg2', 'pool_recycle': 3600},
'customer_id': '43cab1f4-de60-4ab1-85b5-1d883c5c5d09'},
'raas': {'raas': '5.2.0-762-g3a64d15' ...
error=None,
warnings=[])
28.8.3 audit interface
Audit RPC endpoint
get_audit(…)
Returns Dict.
Return a list of audit records matching search criteria.
Table 28.2: get_audit() parameters

account_uuid Account UUID to match on audit records. Cannot be
combined with username
username Username to match on audit records. Cannot be com-
bined with account_uuid
session_uuid Session UUID, to match retrieve audit records from a
particular client session
event_type 'system', 'auth', 'rpc', or 'task'
event_name For system events, 'startup' or 'shutdown'.
For auth events, 'login' or 'logout'. For rpc
events, '<resource>.<method>' of the API call.
For task events, the name of the background task.
failed True to match failed events, False to match successful
events
daterange List of two date strings in ISO 8601 format
elapsed_msec_min Minimum event duration, in milliseconds
elapsed_msec_max Maximum event duration, in milliseconds
page Which page of the records to return (offset = page *
limit)
limit How many records to return at a time
sort_by Field to sort by ('username', 'event_type',
'event_name', 'failed', 'start_time',
'end_time', 'elapsed_msec')
reverse True to reverse sort order
client.api.audit.get_audit(username='root', event_type='auth', failed=True)
RPCResponse(
riq=4,
ret={'count': 1,
'results': [

{'id': 175,
'start_time': '2019-06-05T21:12:53.190506+00:00',
'end_time': '2019-06-05T21:13:24.729561+00:00',
'event_type': 'auth',
'event_name': 'login',
'username': 'root',
'account_uuid': None,
'session_uuid': '4642ef92-d5ac-4ea2-b95d-2055b43f2193',
'failed': True,
'event_data': {
'note': 'User root: authentication failed: invalid basic-auth
˓→credentials',
'status': 401,
'headers': {
'Host': 'localhost:8080',
'Accept': '*/*',
'User-Agent': 'curl/7.65.0',
'Content-Type': 'application/x-www-form-urlencoded',
'Authorization': 'Basic cm9vdDpzYWx0MQ==',
'Content-Length': '41'}}}],
error=None,
warnings=[])
28.8.4 auth interface
Users/Groups/Roles RPC Management
save_group_link(…)
Returns None.
Link an external auth backend group to an SSE internal group. Users in the external group will inherit the roles
assigned to the SSE group.
Table 28.3: save_group_link() parameters

group_name Name of the SSE group to be linked to the external
group
group_uuid UUID of the SSE group. Pass either group_uuid or
group_name to uniquely identify the SSE group.
config_name Name of the authentication backend of the external
group
ext_group_name Name of the external group to be linked to the SSE
group
ext_group_uid Unique ID of the external group. Pass
config_name and either ext_group_name
or ext_group_uid to uniquely identify an
external group.
delete_role(…)
Returns None.
Delete a role from the system.

Table 28.4: delete_role() parameters

role_name Name of the group to be deleted.
role_uuid UUID for this group. When calling this endpoint, use
either role_uuid or role_name to uniquely iden-
tify a role.
save_group(…)
Returns [‘None’, ‘Dict’].

Save a group. This call supports both creating groups and updating group information.
Table 28.5: save_group() parameters

config_name Name of the authentication backend to which this
group belongs
group_name Name of this group. Changing a group name is only
supported for the internal authentication back-
end.
group_uuid UUID for this account. When calling this end-
point, use either group_uuid or config_name
and group_name to uniquely identify a group.
description Text describing the group purpose.
roles A list of roles to assign to this group. See Roles and
Permissions
custom_data A dictionary containing arbitrary data. Authentica-
tion backends can use this to store information to
assist in aligning groups in RaaS with groups in the
backend. For example, the Active Directory backend
uses it to store a group’s Distinguished Name.
remote_uid Externally defined group unique id.
get_user(…)
Returns Dict.
Get details for a user account. See Local Users for more details about the user model.
Table 28.6: get_user() parameters

account_uuid UUID of the user for which the call should retrieve
details. This parameter cannot be combined with
username
username Username of the account for which the call should
retrieve details. This parameter cannot be combined
with username, and requires that config_name
also be passed
config_name Authentication/Authorization backend name
(internal, ldap, etc.)
client.api.auth.get_user(account_uuid='80c67364-cb31-4f4b-972a-e7ea3f752bb8')

RPCResponse(riq=12,
ret={'uuid': '80c67364-cb31-4f4b-972a-e7ea3f52bb8',
'groups': [],
'perms': ['cmd-read', 'master-config-read',
'job-run', 'fs-read', 'cloud-read',
'job-read', 'superuser', 'returner-read',
'metadata-auth-read', 'target-read',
'license-read', 'master-fs-read',
'minion-read', 'master-read'],
'config_name': 'internal',
'custom_data': None,
'roles': ['Superuser', 'User'],
'username': 'root'}, error=None, warnings=[])
save_role(…)
Returns None.
Update an existing or create a new role.
See Roles and Permissions for more details about roles in SaltStack Enterprise.
Table 28.7: save_role() parameters

role_name Name of the role in question.
role_uuid UUID for this role.
perms A list of permissions to assign to this role. See API
Permission values and Roles and Permissions.
description Text to describe nature and purpose of the role.
change_password(…)
Returns None.
Update a password for an account_uuid.
delete_user(…)
Returns None.
Delete a user account.
Table 28.8: delete_user() parameters

user account belongs
username User’s login name.
account_uuid UUID for this account. When calling this endpoint,
use either account_uuid or config_name and
username to uniquely identify an account.

save_user(…)
Returns UUID.
Save a user account. This call supports both creating accounts and updating user account information.
See Local Users for more details about the user model.
Table 28.9: save_user() parameters

user account belongs
username User’s login name. Changing a username is only sup-
ported for the internal authentication backend.
password Account password. (account creation only)
account_uuid UUID for this account. When calling this endpoint,
use either account_uuid or config_name and
username to uniquely identify an account.
perms A list of permissions to assign to this account. See API
Permission values.
roles A list of roles to assign to this account. See Roles and
Permissions.
groups A list of groups to assign to this account
custom_data A dictionary containing arbitrary data. Authentica-
tion backends can use this to store information to as-
sist in aligning users in RaaS with users in the back-
end. For example, the Active Directory backend uses
it to store the users Distinguished Name.
get_role(…)
Returns Dict.
Retrieve details about a particular role. See Roles and Permissions for more information on roles and how they
function.
Table 28.10: get_role() parameters

role_name Name of the role to retrieve.
role_uuid UUID of the role to retrieve. Use role_name or
role_uuid but not both.
Example:
delete_group_link(…)
Returns None.
Delete the link between an external auth backend group and an SSE internal group.

Table 28.11: delete_group_link() parameters

group_name Name of the SSE group to be linked to the external
group
group_uuid UUID of the SSE group. Pass either group_uuid or
group_name to uniquely identify the SSE group.
config_name Name of the authentication backend of the external
group
ext_group_name Name of the external group to be linked to the SSE
group
ext_group_uid Unique ID of the external group. Pass
config_name and either ext_group_name
or ext_group_uid to uniquely identify an
external group.
get_group_links(…)
Returns List[Dict].
Get information on links between external auth backend groups and SSE internal groups.
Table 28.12: get_group_links() parameters

group_name SSE group name (substring match)
group_uuid SSE group UUID
config_name Name of the authentication backend (substring
match)
ext_group_name External group name (substring match)
ext_group_uid External group unique ID
get_all_users(…)
Returns List[Dict].
Get all users for the provided config_name or all users of all authentication configurations if the value of
config_name is None
See Local Users for more details about the user model.
Table 28.13: get_all_users() parameters

config_name Authentication/Authorization backend name
(internal, ldap, etc.)
include_roles Include roles assigned to this user
include_perms Include permissions assigned to this user
include_groups Include groups to which this user belongs
include_custom_data Include any custom data assigned to this user
last_uuid Used in conjunction with page_size to indicate
where to continue pagination
page_size Limit results to this number of records. Combine
with last_uuid to achieve pagination through all
records efficiently.
sort_order SQL keyword for order of result set (ASC, DESC)

client.api.auth.get_all_users(config_name='internal', include_roles=True)
RPCResponse(riq=13,
ret=[{'config_name': 'internal',
'uuid': '80c67364-cb31-4f4b-972a-e7ea3f752bb8',
'roles': ['Superuser', 'User'], 'username': 'root'},
{'config_name': 'internal',
'uuid': '59c4c....}], error=None, warnings=[])
get_group(…)
Returns Dict.
Retrieve information about a group.
Table 28.14: get_group() parameters

group account belongs
group_name Name of the group
group_uuid UUID for this group. When calling this endpoint,
use either group_uuid or config_name and
group_name to uniquely identify a group.
include_users If this parameter is true, include the members of the
group in the return.
get_jwt(…)
Returns Dict.
Get a JSON Web Token for the current user.
save_user_link(…)
Returns None.
Create a link between an external user and an internal RaaS user. Will create an internal user record if necessary.
Table 28.15: save_user_link() parameters

config_name Name of the authentication backend (substring
match)
username Username to link
user_dn DistinguishedName in the external directory
transfer_resources(…)
Returns Dict.
Transfer resources that belong to one user to another.

Table 28.16: transfer_resources() parameters

from_user_uuid UUID of the user whose resources are to be trans-
ferred.
to_user_uuid UUID of the user to whom the resources are to be
transferred.
resource_types The type of the resource that is to be trans-
ferred (Optional). target_groups, jobs, files,
pillars, auth_configs, formulas are valid
inputs.
resource_uuids The UUID of the resources that are to be transferred.
(Optional).
revoke_access Revoke access on the resource after transfer.
test Return the number of resources to be updated without
updating ownership.
delete_group(…)
Returns None.
Delete a group from the provided named configuration
Table 28.17: delete_group() parameters

group belongs
group_name Name of the group to be deleted.
group_uuid UUID for this group. When calling this endpoint,
use either group_uuid or config_name and
group_name to uniquely identify a group.
get_all_groups(…)
Returns [‘Dict’, ‘List’].

Return all groups from the provided named configuration.
Table 28.18: get_all_groups() parameters

config_name Name of the authentication backend from which
groups should be retrieved.
include_roles Include roles in result (see Roles and Permissions)
include_users Include users belonging to this group
include_custom_data Include any custom data assigned to this group.
last_uuid Used in conjunction with page_size to indicate
where to continue pagination
page_size Limit results to this number of records. Combine
with last_uuid to achieve pagination through all
records efficiently.
sort_order SQL keyword for order of result set (ASC, DESC)

get_all_roles(…)
Returns Dict.
Retrieve details about all roles in the system.
Example:
28.8.5 background_jobs interface
Endpoint to query running background jobs for their status
get_background_job(…)
Returns Dict.
Return the status information about a background running job
get_task_status(…)
Returns List.
Get the status of background tasks
task_ids list of task IDs
28.8.6 cloud interface
The RPC methods for the cloud interface
28.8.7 cmd interface
The RPC methods for the command interface
pause_job(…)
Returns str.
Pass a pause command through to the masters. Note that the pause command is itself a command, so this method
returns a jid corresponding to the state.pause call.
param job_uuid UUID of the job to attempt to pause
param jid Jid of the job to attempt to pause
return a Jid corresponding to the pause command

get_cmd_details(…)
Returns Dict.
Query commands based on jid and retrieve more detailed data.
jid A job ID to match against.
minion_id_exact Filter by a minion_id that match exactly. Also full return data will be returned.
minion_id Filter by a minion_id search.
master_id Filter by a master_id search.
has_errors Filter by whether there were errors, True|False.
has_return Filter by whether return data was recieved, True|False.
sort_by Sort by the specified field, such as ‘alter_time’.
reverse Sort ascending (False) or descending (True).
page This specifies which page, after the first, of results to return. Often used with limit.
limit This is how many records to return at a time. The default is 50. Often used with page.
Examples
Request

client.api.cmd.get_cmd_details(
jid="20190726204734431402"
)
get_cmds(…)
Returns Dict.
Query commands based on a number of properties.
See Jobs for more information on commands and jobs.

Table 28.19: get_cmds() parameters

cmd A command name to match against.
daterange A comma-separated list of two date strings in
ISO 8601 format.
filter_find_job Exclude commands referring to
saltutil.find_job.
filter_refresh_grains Exclude commands referring to saltutil.re-
fresh_grains.
fun Command (function) name that was called for
this job.
highstate True if the job submitted was call to state.high-
state
include_adhoc When this is true, you can search jobs
that are running (in-flight), but were
not scheduled via the scheduler API
(ad-hoc). This parameter is deprecated.
Use include_adhoc_scheduled
instead. Until the removal of this pa-
rameter, it will take precedence over
include_adhoc_scheduled if it
is present. If it is not present or is
passed a value of None, the value of
include_adhoc_scheduled will be
honored.
include_ad- One of all, scheduled, or adhoc. Filters
hoc_scheduled jobs based on if they are scheduled, unsched-
uled (aka “on the fly” or “ad-hoc”, or show all
jobs regardless of what started them.)
limit This is how many records to return at a time.
The default is 50. Often used with page.
jid A job ID to match against.
job_names A list of job names to match against.
job_uuid Every job gets a jid and a UUID. This is the uuid
for the job.
master_id Master ID
page This specifies which page, after the first, of re-
sults to return. Often used with limit.
sched_names A list of schedule names to match against.
sched_uuid A schedule UUID to match against.
sort_by Sort by the specified field, such as ‘start_time’.
state_invert Return commands that do not have the specified
state.
state Find commands in one of these states, 'new',
'retrieved', 'skipped', 'pausing',
'paused', 'resuming', 'resumed',
'completed_missing_returns',
'completed_failures',
'completed_all_successful',
'stopping', 'stopped', or
'disabled'. Note that state may
contain completed when no minions have
returned. For more information, see Activity.
tgt_names A list of target names to match against.
156 tgt_uuid Chapter 28.Commands
Enterprise can
API be(eAPI)
targeted
RPCdirectly or via
Endpoint a
Documentation
saved target group. This is the UUID of the tar-
get group used to submit the command.
users A list of users to match against.
Example:
client.api.cmd.get_cmds()
RPCResponse(riq=5,
ret={'count': 1,
'results': [
{'cmd': 'local',
'duration': None,
'expected': 2,
'fun': 'disk.usage',
'is_highstate': False,
'jid': '20190416202619938862',
'job_desc': None,
'job_name': None,
'job_source': 'raas',
'job_uuid': None,
'masters_done': ['master1'],
'masters_to': ['master1'],
'origination': 'Ad-Hoc',
'returned': 1,
'returned_failed': 0,
'returned_good': 1,
'sched_name': None,
'sched_uuid': None,
'start_time': '2019-04-16T20:26:19.93886Z',
'state': 'retrieved',
'tgt_desc': None,
'tgt_name': None,
'tgt_uuid': None,
'user': 'root',
'user_uuid': '80c67364-cb31-4f4b-972a-e7ea3f752bb8'}]},
error=None,
warnings=[])
stop_job(…)
Returns str.
Pass a ‘soft_kill’ command through to the masters.
param job_uuid UUID of the job to attempt to kill
param jid Jid of the job to attempt to kill
return a Jid corresponding to the kill command
route_cmd(…)
Returns str.
Create a command and route it to Salt. See Jobs for more information on commands and jobs.

Table 28.20: route_cmd() parameters

job_uuid UUID for this job, can be None in which case RaaS
will generate a new UUID.
cmd One of local (for targeting minions), runner
(master-level command), or wheel (master wheel
calls)
fun Dotted-notation function to run (e.g. test.ping or
network.ipaddrs)
masters A list of master names that should receive this com-
mand. Applicable only for runner and wheel com-
mands. For local cmds all targeting is specified in
tgt.
arg A dictionary containing the keys arg and/or kwarg
representing arguments to pass to the fun being
called.
tgt A dictionary containing targeting information. See
Minions and targets for more information. A target
can contain a master name of * to indicate all Salt-
Stack Enterprise-connected masters. If * is present, it
must be the only master listed in tgt.
tgt_uuid The UUID of an existing target group that should re-
ceive this command.
Either tgt or tgt_uuid should be used, but not both.

tgt has the following form:
{ name_of_master: { 'tgt': target_string,

'tgt_type': target_type` },
name_of_master: { 'tgt': target_string ... }}
Example:
client.api.cmd.route_cmd(cmd='local',
fun='cmd.run',
tgt={'master3_master': {'tgt': 'master3', 'tgt_type':
˓→'glob'}},
arg={'arg': ["ls /etc"]})
client.api.cmd.route_cmd(
job_uuid='5c5cc410-4f9f-11e6-88bc-080027a7289c',
tgt={'master3_master': {'tgt': '*', 'tgt_type': 'glob'}})
Example with an argument:
client.api.cmd.route_cmd(cmd='local',
fun='cmd.run',
tgt={'master3_master': {'tgt': 'master3', 'tgt_type': 'glob'}},
arg={'arg': ["ls /etc"]})
Example with an existing job_uuid
client.api.cmd.route_cmd(job_uuid='5c5cc410-4f9f-11e6-88bc-080027a7289c',
tgt={'master3_master': {'tgt': '*', 'tgt_type': 'glob'}})

resume_job(…)
Returns str.
Pass a resume command through to the masters
param job_uuid UUID of the job to attempt to resume
param jid Jid of the job to attempt to resume
return a Jid corresponding to the resume command
get_cmd_status(…)
Returns List.
Get the status of a command
jids list of JIDs
28.8.8 conf interface
The RPC endpoints for the master config interface
28.8.9 formula interface
RPC methods for managing formulas
28.8.10 fs interface
The RPC methods for the fileserver interface
get_env(…)
Returns List[Dict].
List all files in the given Salt environment.
See Environments for more information.
Table 28.21: get_env() parameters

saltenv Salt environment in which to look for the files
include_fs_metadata If True, include a dictonary key that has metadata as-
sociated with the file.
save_file(…)
Returns None.
Add or update a file to the database
See File Server and Environments for more information.

Table 28.22: save_file() parameters

file_uuid UUID of the file in question
saltenv Salt environment in which to look for the file
path Fully-qualified path of the file.
contents The file’s contents. If the file is plain text then
contents is the literal content of the file. If
it is a binary format then contents should be
base64-encoded.
content_type MIME content-type. Will be guessed if passed in as
None.
Note, use file_uuid or saltenv and path, but not both.
file_exists(…)
Returns bool.
Return True if file exists.
Table 28.23: file_exists() parameters

delete_file(…)
Returns None.
Delete a file from the database.
Table 28.24: delete_file() parameters

get_envs(…)
Returns List[str].
Get a list of all available Salt environments
See Environments for more information.

update_file(…)
Returns None.
Add or update a file to the database
Table 28.25: update_file() parameters

contents The file’s contents. If the file is plain text then
contents is the literal content of the file. If
it is a binary format then contents should be
base64-encoded.
content_type MIME content-type. Will be guessed if passed in as
None.
get_file(…)
Returns Dict.
Get a file from the database. Returns a dictionary with the file’s metadata and a data field with the actual file contents.
Table 28.26: get_file() parameters

get_file_access(…)
Returns Dict.
Return access metadata for this file.
Table 28.27: get_file_access() parameters

file_uuid UUID referencing desired file.
save_file_access(…)
Returns None.
Save access metadata for this file.

Table 28.28: save_file_access() parameters

job_uuid UUID referencing desired file.
access_payload Dictionary containing role names as keys and a list of
allowed access types as values
28.8.11 job interface
The RPC methods for the jobs interface
save_job_access(…)
Returns UUID.
Save access metadata for this job.
Table 28.29: save_job_access() parameters

job_uuid UUID referencing desired job.
get_job_access(…)
Returns Dict.
Return access metadata for this job.
Table 28.30: get_job_access() parameters

job_uuid UUID referencing desired job.
get_jobs(…)
Returns Dict.
Get a job by uuid or search jobs by other query parameters.

Table 28.31: get_jobs() parameters

param uuid job_uuid UUID referencing job. If left blank, all jobs are re-
turned.
param str name Text to search for in the job name
param str desc Text to search for in the job description
param str cmd Job command to match (‘local’, ‘runner’, ‘wheel’, or
‘ssh’)
param UUID tgt_uuid Target group UUID to match
param UUID role_uuid Role UUID to match (Admins only)
param bool in- Include jobs that have no tgt_uuid as well
clude_no_tgt_jobs
param str fun Salt function to match (e.g., ‘test.ping’)
param list masters List of salt master ids to match
param str sort_by Field to sort by (‘name’, ‘desc’, ‘cmd’, or ‘fun’)
param bool reverse Whether to sort in descending order
param int limit Maximum number of jobs to return, default 50
param int page Page of jobs to return (offset = page * limit)
The flag include_no_tgt_jobs is intended to be used when a list of jobs that can be run at the time is desired. For
example, if a user clicks on a target in the GUI and is presented with a list of jobs that go with that target, we may
also want to show jobs that have NO target attached since those jobs may be run regardless of what target is selected.
This flag has no effect if tgt_uuid is None.
The return payload is a dict with the following elements:
{
'count': 100, # total job count
'limit': 50, # results count
'results': [...] # jobs
}
delete_job(…)
Returns None.
Delete a job.
Table 28.32: delete_job() parameters

job_uuid UUID referencing job to be deleted.
force Force deletion of target group even with schedule jobs
depending on it(which will also get deleted).
raises FailedResourceDependency The job has one or more schedules that depend on it and force is
false. The details of the exception contain the results of get_schedules with the dependent sched-
ules.
save_job(…)
Returns str.
Create or update a job

Table 28.33: save_job() parameters

name Name to give to the job.
desc Descriptive text for job.
cmd One of local (for targeting minions), ssh (aka salt-ssh),
runner (master-level command), wheel (master wheel
calls)
fun Dotted-notation function to run (e.g. test.ping or net-
work.ipaddrs)
arg A dictionary containing the keys arg and/or kwarg
representing arguments to pass to the fun being
called.
masters A list of master names that should receive this com-
mand.
job_uuid UUID referencing job. If left blank, one will be gen-
erated. If not blank, but no job with this UUID exists,
a new job is created. If not blank and a UUID exists,
that job is updated with the passed information.
tgt_uuid UUID for a target group.
This endpoint returns the UUID for the job.
28.8.12 kv interface
Key/value store API
delete_system_key(…)
Returns int.
Delete a system key. System keys are used internally and cannot be retrieved directly.
Table 28.34: delete_system_key() parameters

key The system key to delete.
Returns the number of system keys deleted (0 or 1).
set_system_key(…)
Returns None.
Set the value of a system key. System keys are used internally and cannot be retrieved directly.
Table 28.35: set_system_key() parameters

key The system key to set.
value The value to set.
28.8.13 license interface
The RPC methods for license management

check_usage(…)
Returns Dict.
Return a dictionary that contains information about the license status.
Table 28.36: check_usage() parameters

force_check If False uses information cached over time
since getting actual usage can be somewhat time-
consuming for large environments. If True forces
the usage calculation and then returns results.
Note: Make sure to track your license status and keep it active. If your license expires, the SaltStack Enterprise
service will stop.
Example:
client.api.license.check_usage()
RPCResponse(riq=17,
ret={u'timestamp': u'2017-11-30T15:58:24.475034',
u'messages': [{u'detail': u'license expires 2018-06-01',
u'level': u'info'},
{u'detail': u'4 masters in use is within hard limit of 10',
u'level': u'info'},
{u'detail': u'4243 minions in use is within hard limit of 10000
˓→',
u'level': u'info'}]},
error=None, warnings=[])
get_license(…)
Returns Dict.
Return license for the passed uuid.
• UUID for the desired license.
get_usage_snapshots(…)
Returns List.
Return snapshots of license usage for a given date range.
Snapshots are normally taken every hour.
Table 28.37: get_usage_snapshots() parameters

date_start Initial snapshot date.
date_end Final snapshot date.
Example:

client.api.license.get_usage_snapshots('2017-11-01','2017-11-17')
RPCResponse(riq=25,
ret=[{u'license_uuid': u'1dbb6f3c-c622-11e6-874c-002590058d18',
u'masters': 4,
u'minions': 4212,
u'datetime': u'2017-11-16T18:06:49.171497'},
{u'license_uuid': u'1dbb6f3c-c622-11e6-874c-002590058d18',
u'masters': 4, u'minions': 4243,
u'datetime': u'2017-11-16T19:55:26.095901'},
{u'license_uuid': u'1dbb6f3c-c622-11e6-874c-002590058d18',
u'masters': 4,
u'minions': 4222,
u'datetime': u'2017-11-16T20:55:26.092793'} .... ],
delete_license(…)
Returns None.
Delete the license for this uuid. Deleting the active license with no alternative license in place can cause RaaS to
stop working.
• UUID for the license to be deleted.
get_current_license(…)
Returns Dict.
Retrieve the current active license for RaaS.
Note: Make sure to track your license status and keep it active. If your license expires, the SaltStack Enterprise
service will stop.
Example:
c.api.license.get_current_license()
RPCResponse(riq=16,
ret={u'alter_time': u'2017-11-15T23:39:04.227752',
u'uuid': u'1dbb6f3c-c622-11e6-874c-002590058d18',
u'license': {u'masters':
{u'policy': u'fixed',
u'hard_limit': 10},
u'term': {u'duration': -1,
u'policy': u'fixed'},
u'features': [u'*'],
u'minions': {u'policy': u'fixed',
u'hard_limit': 10000},
u'metadata': {u'customer': u'SaltStack',
u'uuid': u'1dbb6f3c-c622-11e6-874c-002590058d18',
u'created': u'2016-12-19'}},
u'desc': [u'Customer: SaltStack',

u'License UUID: 1dbb6f3c-c622-11e6-874c-002590058d18',

u'Created: 2016-12-19',
u'Duration: UNLIMITED',
u'Masters: up to 10',
u'Minions: up to 10000',
u'Features: *']},
28.8.14 master interface
The RPC methods for the salt masters interface
get_master_keys(…)
Returns List.
List RSA keys of masters.
Table 28.38: get_master_keys() parameters

state (Required) accepted, pending, or rejected.
get_master_grains(…)
Returns Dict.
Get grains for a master.
Table 28.39: get_master_grains() parameters

master_id ID (not UUID) of the master.
master_uuid UUID for the master.
split_cluster If True return the grains for the individual master. If
False return the grains for the cluster in which the
master resides.
Example:
client.api.master.get_master_grains('saltmaster1_master')
RPCResponse(riq=26, ret=
{u'saltmaster1_master': {u'grains': {u'biosversion': u'4.2.amazon',
u'kernel': u'Linux',
u'domain': u'localdomain',
u'uid': 0,
u'zmqversion': u'4.1.4',
u'kernelrelease': u'3.10.0-693.5.2.el7.x86_64
˓→',
...... }}

request_master_key(…)
Returns Dict.
Request RSA Public key for master authentication use.
Table 28.40: request_master_key() parameters

master_id (Required) ID (not UUID) of the master requesting
key.
delete_master(…)
Returns None.
Delete master and its grains from RaaS.
Table 28.41: delete_master() parameters

master_id ID (not UUID) of the master to delete.
master_uuid UUID of the master to delete.
Note: use master_id or master_uuid, but not both.
rotate_master_key(…)
Returns Dict.
Rotate RSA Public key for master authentication use.
Table 28.42: rotate_master_key() parameters

master_id (Required) ID (not UUID) of the master requesting
key.
save_master(…)
Returns str.
Update or add a salt-master to the database.
Returns the UUID of the master in the database.
Table 28.43: save_master() parameters

master_id ID (not UUID) of new/updated master
cluster_id ID of cluster to which this master belongs or None if
no cluster is in place.
master_uuid UUID of master. If blank and no master with
master_id exists a new one will be assigned.
grains Master-level grains for this new master.

get_master_jwt(…)
Returns Dict.
Get a JWT authenicating using a master RSA key pair
Table 28.44: get_master_jwt() parameters

master_id (Required) ID (not UUID) of the master.
encrypted_message (Required) Encrypted JSON message with {created,
master_id}.
set_master_key_state(…)
Returns List.
Set RSA key state of masters.
Table 28.45: set_master_key_state() parameters

masters (Required) Master IDs
action (Required) accept, reject, delete.
28.8.15 masterfs interface
The RPC methods for the salt masters FS interface
get_masterfs(…)
Returns Dict.
Get a list of master filesystem files
Table 28.46: get_masterfs() parameters

master_id ID (not UUID) of master
28.8.16 minions interface
The RPC methods for the salt minions interface
get_minion_key_state(…)
Returns Dict.
Get minion key states

Table 28.47: get_minion_key_state() parameters

master_id Filter results by master id.
minion_id Filter results by minion id.
key_state Limit results to this minion key state (accepted,
rejected, pending, or denied).
sort_by Sort results by this field (master_id, minion_id,
or key_state).
reverse Pass True to sort results in descending order.
page Return data from this page number.
limit Set page size (maximum number of results to return).
get_minion_details(…)
Returns Dict.
Get minion details.
Table 28.48: get_minion_details() parameters

master_id Filter minions by master id.
minion_id Filter minions by minion id.
tgt_uuid Limit the query to minions matching this target
group.
grains Filter the minions by matching grains.
sort_by Sort results by this minion grain.
reverse Pass True to sort results in descending order.
page Return data from this page number.
limit Set page size (maximum number of minions to re-
turn).
delete_minion_cache(…)
Returns None.
Flush the minion’s cache on a master.
Table 28.49: delete_minion_cache() parameters

minion_id ID of minion for which the cache should be flushed.
set_minion_key_state(…)
Returns Dict.
Set the minion key state on the provided master id/cluster id.

Table 28.50: set_minion_key_state() parameters

state accept, delete, or reject
minions list of [master_id, minion_id] pairs to set
include_accepted include accepted keys along with pending keys,
works with reject state only
include_rejected include rejected keys along with pending keys, works
with accept state only
include_denied include denied keys along with pending keys, works
with accept and reject state only
get_minion_cache(…)
Returns Dict.
Retrieve the minion cache for a particular master.
Table 28.51: get_minion_cache() parameters

master_id ID for master.
minion_id ID for minion.
Example:
client.api.minions.get_minion_cache(master_id='saltmaster1_master',
minion_id='s01-m01')
{u'saltmaster1_master':
{u's01-m01':
{u'grains':
{u'biosversion': u'4.2.amazon',
u'kernel': u'Linux',
u'domain': u'us-west-1.compute.internal', ..... }}}},
get_minion_grain_values(…)
Returns List[str].
Get a list of unique minion grain values for a particular key, optionally filtering by master id, minion id, or target
group.
Table 28.52: get_minion_grain_values() parameters

key Get possible minion grain values for this minion grain
key
master_id Limit the query to minion grains reported by this mas-
ter
minion_id Limit the query to grains from this minion
tgt_uuid Limit the query to minions matching this target group
Note: when enable_grains_indexing: False this will always return an empty list.

get_minion_grain_keys(…)
Returns List[str].
Get a list of unique minion grain keys, optionally filtering by master id, minion id, or target group.
Table 28.53: get_minion_grain_keys() parameters

master_id Limit the query to minion grains reported by this mas-
ter
minion_id Limit the query to grains from this minion
tgt_uuid Limit the query to minions matching this target group
Note: when enable_grains_indexing: False this will always return an empty list.
delete_minion_key_state(…)
Returns None.
Remove all key states from a particular master.
Table 28.54: delete_minion_key_state() parameters

master_id ID (not UUID) of master.
save_minion_key_state(…)
Returns None.
Save minion key state for a given master.
This function should only be called by a salt-master.
Table 28.55: save_minion_key_state() parameters

master_id ID (not UUID) for the master to update.
keys Dictionary containing key state for minions. This dic-
tionary needs to be in this format:
get_minion_presence(…)
Returns Dict.
Retrieve presence status for all minions in the infrastructure.
Example:
client.api.minions.get_minion_presence()
RPCResponse(riq=6543, ret={
'results': [
{'minion': 's01-m01', 'master': 'saltmaster1_master', 'status': 'present
˓→', 'timestamp': u'2017-11-27T23:06:12.674176'},
{'minion': 's01-m02', 'master': 'saltmaster1_master', 'status': 'lost',

˓→'timestamp': u'2017-11-27T23:06:12.674176'}
],

'count': 2
},
save_minion_cache(…)
Returns None.
Update the minion data cache for a given master. Note that data about minions with unaccepted keys will be ignored.
This function should be called only by a salt-master.
Table 28.56: save_minion_cache() parameters

minions A dictionary keyed by minion id where each value
is the set of grains to be saved to RaaS for that
minion. All existing minion grains from this mas-
ter will be discarded before the new minion grains
are saved. This parameter is mutually exclusive with
minions_delta.
minions_delta A dictionary specifying changes to minion grains data
to be made in RaaS. The top-level key save contains a
dictionary keyed by minion id where each value con-
tains the grains to save for that minion. Any exist-
ing grains data for a particular minion will be dis-
carded before the new grains are saved. The top-level
key remove contains a list of minion ids identifying
grains data to remove from RaaS.
28.8.17 pillar interface
The RPC methods for interacting with pillar
get_pillars(…)
Returns Dict.
Get the data for the given pillar. See Pillars for more information.
Table 28.57: get_pillars() parameters

param pillar_uuid UUID of the pillar structure desired.
param name name for this particular pillar entry
The return payload is a dict with the following elements:
{
'count': 100, # total job count
'results': [...] # jobs
}

save_pillar(…)
Returns str.
Set data in the requested pillar. See Pillars for more information.
Table 28.58: save_pillar() parameters

pillar Data structure to save for this pillar.
pillar_type Type of pillar
pillar_uuid UUID for pillar–if blank a new one will be generated
name Name for this particular pillar entry
desc Text describing this pillar entry.
delete_pillar(…)
Returns None.
Delete pillar for the given UUID.
Table 28.59: delete_pillar() parameters

pillar_uuid UUID of pillar to delete.
get_pillar_access(…)
Returns Dict.
Get the access metadata for a pillar entry.
Table 28.60: get_pillar_access() parameters

pillar_uuid Retrieve metadata for pillar matching this UUID.
save_pillar_access(…)
Returns None.
Save the access metadata for a target group.
Table 28.61: save_pillar_access() parameters

pillar_uuid Save metadata for pillar matching this UUID.
28.8.18 remote interface
Remote control raas
28.8.19 ret interface
Returner RPC interface

get_jid(…)
Returns Dict.
Get the results for a specific job by its job id (jid).
More information on jobs can be found here: Jobs.
Table 28.62: get_jid() parameters

jid Job ID.
get_fun(…)
Returns Dict.
Return a dictionary of the last function called for all minions. Including fun will restrict the result set to minions
for which fun was their last function called.
Table 28.63: get_fun() parameters

fun Limit result set to minions that called this function
last.
get_minions(…)
Returns Dict[str, List[str]].

Returns a dictionary of the current list of known minion IDs keyed by master ID
get_returns() by JID example:
client.api.ret.get_returns(jid='20171205214029544461')
get_returns() by function example:
client.api.ret.get_returns(minion_id='minion1')
get_returns () by minion ID example:
client.api.ret.get_returns(minion_id='minion2')
Example:
client.api.ret.get_minions()
{u'saltmaster1_master':
[u's01-m01', u's01-m02', u's01-m03', ....],
u'saltmaster2_master':
[u's02-m01', u's02-m02', u's02-m03', ....],
u'saltmaster3_master':
[u's03-m01', u's03-m02', u's03-m03', ....]},

get_jids(…)
Returns Dict.
Get all Job IDs for a given range. Warning, with no boundaries this call can return a huge amount of data.
More information on jobs can be found here: Jobs.
Table 28.64: get_jids() parameters

start Timestamp from which to start.
end Timestamp at which to end.
limit Maximum number of job entries to return.
get_returns(…)
Returns Dict.
Return job results from the job cache based on the provided arguments.
For more on job returns, see Job Returns.
Table 28.65: get_returns() parameters

jid Job ID.
master_id Return results only for jobs run on this master.
minion_id Return results only for jobs executed on this minion.
fun Return results for this called function.
user Restrict results to jobs executed by this user.
job_name Filter by job_name
job_uuid Return results for this job’s UUID (not Job ID (jid))
tgt_name Filter by tgt_name
tgt_uuid Return job results executed via this target group.
match_tgt_uuid Return job results for jobs matching this target group.
args filter by an argument string
highstate Return only results that were generated via highstate.
start Return results starting from this timestamp.
end Stop returning results at this timestamp.
limit Limit results to this number of jobs.
has_errors Return results for those jobs with errors.
sort_by Return results sorted by minion_id, function, has_er-
rors, or jid.
reverse Return results sorted in the reverse order.
page Return job results from this page. Page starts from 0.
get_returns() example:
client.api.ret.get_returns()
The return payload is a dictionary with the following elements:

{
'count': 100, # total job returns count
'results': [...] # job returns
}

Example:
client.api.ret.get_returns(jid='20150430164924016227')
RPCResponse(
{ 'count': 1,
'limit': 1,
'results': [ { 'alter_time': '2018-06-29T21:29:37.720943',
'full_ret': { '_stamp': '2015-04-30T16:49:24.379894',
'cmd': '_return',
'fun': 'pillar.items',
'fun_args': [],
'id': 'raas_test_ret_returns_minion',
'jid': '20150430164924016227',
'master_id': 'raas_test_ret_returns_master',
'retcode': 0,
'return': { 'baz': 'qux',
'lxc-cluster': True,
'qux': 'baz'},
'success': True},
'fun': 'pillar.items',
'fun_args': [],
'has_errors': False,
'jid': '20150430164924016227',
'master': 'raas_test_ret_returns_master',
'master_uuid': '5c56659b-0619-45bc-8ad7-e805c28d85ce',
'minion_id': 'raas_test_ret_returns_minion',
'return': {'baz': 'qux', 'lxc-cluster': True, 'qux': 'baz'}}]})
get_load(…)
Returns Dict.
Return the load for the given JID from the given master.
Table 28.66: get_load() parameters

master_id ID for the master (not UUID)
jid Job ID.
28.8.20 roster interface
The RPC methods for the roster interface
28.8.21 schedule interface
Interface with the time scheduler inside raas.
save(…)
Returns UUID.
Add/update a component in the schedule.
See Schedules for more information.

param str name The name of the schedule item

param dict schedule A dictionary with schedule details.
param list masters List of masters on which to execute runner and wheel commands.
param str cmd One of local, runner, ssh, wheel
param dict arg Argument dictionary containing kwargs and args for fun below
param dict tgt The minion target dictionary (use this or tgt_uuid, not both)
param str tgt_uuid a UUID for an already saved target (use this or tgt, not both)
param str job_uuid a UUID for an already saved job (use this or fun+arg, not both)
param str fun The function to run (use this or job_uuid, not both)
param bool enabled Set the schedule job enabled or disabled
arg should have this format:
arg: { 'arg': [<arg1>, <arg2>, ..., <argn>],

'kwarg': { '<key1>': <val1>,
'<key2>': <val2>,
...
'<keyn>': <valn> }
}
schedule should have this format:
schedule: { '<descriptor1>': <value1>,

'<descriptor2>': <value1>,
...
'<descriptorn>': <valuen> }
Descriptor above can be a number of things like seconds, once, when, cron, etc. See the SaltStack Enterprise documen-
tation for a complete list.
remove(…)
Returns bool.
Remove a schedule by uuid.
param uuid The uuid of the schedule to be removed.
futures(…)
Returns Dict.
Get a list of future times when the scheduled jobs will execute. If jobs is passed in then only the futures for those
jobs will be calculated. By default the job times will be queried out for 8 weeks

Table 28.67: futures() parameters

list jobs A list of job names to query
list daterange A list of two date strings in ISO 8601 format in UTC. If
the provided dates are in a different offset, they will be
converted to UTC prior to the date range constrain-
ing.
int limit The number of job instances to return, defaults to 100
The parameter daterange, which is a date string in ISO8601 format has a sibling parameter, daterange_fmt,
which is a string that can represent an alternate date and time format used to parse the daterange values.
get_inflight(…)
Returns Dict.
Get a list of jobs that are in progress.
Table 28.68: get_inflight() parameters

cmd A command name to match against.
filter_find_job Exclude commands referring to saltutil.find_job.
fun Command (function) name that was called for this job.
include_adhoc When this is true, you can search jobs that are run-
ning (in-flight), but were not scheduled via the sched-
uler API (ad-hoc).
job_names A list of job names to match against.
page This specifies which page, after the first, of results to
return.
limit Limit search to this number of jobs.
sched_names A list of schedule names to match against.
sort_by Sort by the specified field, such as ‘start_time’.
tgt_names A list of target names to match against.
paused Filter on only paused jobs.
search_history(…)
Returns Dict.
Query the logs of past scheduler runs.

Table 28.69: search_history() parameters

str query The text to search for
bool name Whether to search schedule names
str cmd One of local, runner, ssh, wheel
str fun The name of the function that was run
list masters The master(s) that the job was assigned to
str tgt A target string to search for
bool arg Whether to search inside *args
bool kwarg Whether to search inside **kwargs
list daterange A list of two date strings in ISO 8601 format
int limit How many records to return at a time
int page Which page of the records to return (offset = page *
limit)
The parameter daterange, which is a date string in ISO8601 format has a sibling parameter, daterange_fmt,
which is a string that can represent an alternate date and time format used to parse the daterange values.
get(…)
Returns Dict.
Return the full schedule json structure.
param list names Matching names of the schedule entries to return
param bool show_past Include entries that were scheduled to run in the past.
param str query The text to search for in args or kwargs
param str fun The name of the function that was run
param list masters A list of masters that the job was assigned to
param str tgt A target string to search for
param bool arg Whether to search inside *args
param bool kwarg Whether to search inside **kwargs
param list state A list of states to match
param bool enabled is the scheduled item enabled to run or not
param UUID uuid Schedule UUID to match
param list job_names A list of job names to match
param list tgt_names A list of target group names to match
param str sort_by Field to sort by
param bool reverse Pass True to sort in descending order
param int limit How many records to return at a time
param int page Which page of the records to return (offset = page * limit)

NOTE: passing ['*'] as the value of masters will match the literal value * in the list of masters. get() is setup
this way so it will be possible to look up schedules that are targeted at all masters. If * was treated as the wildcard,
it would always match any job targeted
at any master
save_skip(…)
Returns Dict.
Update a list of futures (by UUID) skip flag
Table 28.70: save_skip() parameters

list uuids A list of future uuids to set skip flag for.
boolean skip True or False to skip future
update(…)
Returns UUID.
Update a schedule.
param str name The name of the schedule item
param dict schedule A dictionary with schedule details.
param list masters List of masters on which to execute runner and wheel commands.
param dict arg Argument dictionary containing kwargs and args for fun below
param dict tgt The minion target dictionary (use this or tgt_uuid, not both)
param str tgt_uuid a UUID for an already saved target (use this or tgt, not both)
param str job_uuid a UUID for an already saved job (use this or fun+arg, not both)
param str fun The function to run (use this or job_uuid, not both)
param bool enabled Set the schedule job enabled or disabled
arg should have this format:
arg: { 'arg': [<arg1>, <arg2>, ..., <argn>],

'kwarg': { '<key1>': <val1>,
'<key2>': <val2>,
...
'<keyn>': <valn> }
}
schedule should have this format:
schedule: { '<descriptor1>': <value1>,

'<descriptor2>': <value1>,
...
'<descriptorn>': <valuen> }

Descriptor above can be a number of things like seconds, once, when, cron, etc. See the SaltStack Enterprise documen-
tation for a complete list.
28.8.22 sec interface
Security policy compliance RPC interface
get_content_stats(…)
Returns dict.
Get the stats for the lastest ingested content :param hub: :param custom: True|False :return: dict = {
results: None|dict = { uuid, ingest_date, benchmarks, checks
} errors: List of error messages
download_content(…)
Returns None.
Download Locke tarball and expand the files into hub.opts[‘cachedir’] + /locke Once the download and expansion is
complete, call ingest to put them in the raas filesystem
delete_custom_benchmarks(…)
Returns None.
Delete custom benchmarks
Table 28.71: delete_custom_benchmarks() parameters

benchmark_uuids List of custom benchmark UUIDs.
Returns
Returns nothing if the benchmark was successfully deleted
Examples
Request

client.api.sec.delete_custom_benchmarks(
benchmark_uuids=["e912435e-2c38-4cfa-aa1e-985c83aa8a22"]
)

Response
RPCResponse(
riq=4,
ret={},
error=None,
warnings=[])
get_check_variables(…)
Returns Dict.
Get variables for one or more checks
Table 28.72: get_check_variables() parameters

policy_uuid UUID of the policy.
benchmark_uuids List of benchmark UUIDs.
check_uuids List of check UUIDs.
exclude_check_uuids List of check UUIDs to exclude.
sort_by Sort results by supplied field.
reverse Set to True to reverse sort order.
page Return results specified by page number.
limit Maximim number of results to return.
Returns
Returns information about variables for one or more check UUIDs.
Examples
Request

client.api.sec.get_check_variables(
check_uuids=["2e0e216d-1f8e-4e47-9bd5-e0a33ca7665c"]
)
Response
RPCResponse(
riq=4,
ret={
"count": 1,
"results": [{
"check_uuid": "2e0e216d-1f8e-4e47-9bd5-e0a33ca7665c",
"check_name": "locke.system.service.sshd_maxauthtries",
"variables": [{
"name": "_locke.system.service.sshd_maxauthtries.SSHD_CONFIG_
˓→MAXAUTHTRIES",

"uuid": "a0e2a5fc-4a1f-49e8-a27f-55e983491f99",
"scope": "local",
"check_uuid": "2e0e216d-1f8e-4e47-9bd5-e0a33ca7665c",
"description": "Maximum number of authentication attempts permitted
˓→per connection",
"default_value": "4"
}]
}]
},
error=None,
warnings=[])
get_benchmark_dependencies(…)
Returns Dict.
Get the dependencies for a benchmark i.e. which policies and checks reference it
Table 28.73: get_benchmark_dependencies() parameters

benchmark UUID of the benchmark.
Returns
Returns the list of policies and checks that reference this benchmark
Examples
Request

client.api.sec.get_benchmark_dependencies(
benchmark_uuid="e912435e-2c38-4cfa-aa1e-985c83aa8a22"
)
Response
RPCResponse(
riq=4,
ret={
"policies": ["d3c68d55-04d7-4451-8f1e-f2b3e6d9ff3f", "b6da0147-2bbd-4497-b11b-
˓→b9f5548e7297"],
"checks": [{"uuid":"563577e3-e84f-4204-a89b-8456df96c34f", "other_benchmark_

˓→references": True},
{"uuid":"475a6070-56d5-49a0-840b-000efe8780e0", "other_benchmark_
˓→references": False]
},
error=None,
warnings=[])

get_check_details(…)
Returns Dict.
Get detailed information about a check
Table 28.74: get_check_details() parameters

check_uuid UUID of the check.
Response
Details for check matching check UUID.
Examples
Request

client.api.sec.get_check_details(
check_uuid="0c3df74e-d0ca-4c6e-9d2f-39035ff98f7a"
)
Response
RPCResponse(
riq=4,
ret={
"uuid": "0c3df74e-d0ca-4c6e-9d2f-39035ff98f7a",
"name": "locke.system.file.at_cron_authorized_users",
"version": "1",
"display_name": "Ensure at/cron is restricted to authorized users",
"state_fs_uuid": "e78a934f-0355-4fc7-9d4c-3ccb1a5fcb79",
"mini_meta_fs_uuid": "16666977-7d8b-44bd-9cd3-909546673098",
.
.
.
},
error=None,
warnings=[])
download_policy_report(…)
Returns str.
Download report for a policy assessment

Table 28.75: download_policy_report() parameters

jid Job ID of the report to download. This parameter is
optional.
Response
JSON formatted report file.
Examples
Request

client.api.sec.download_policy_report(
policy_uuid="3c625016-9dbf-44d8-b97c-17f4361b78a0"
)
Response
JSON formatted report file.
get_stats(…)
Returns Dict.
Get statistics for SecOps

Table 28.76: get_stats() parameters

include_in_response Stats to include in response. It accepts follow-
ing values checks_assessed_all_time
checks_remediated_all_time
checks_assessed_latest
checks_remediated_latest
assessment_jobs_run
remediation_jobs_run
policies_created
policies_with_schedule
policies_with_expired_schedules
policies_never_assessed
checks_by_benchmark
checks_by_benchmark_in_policy
checks_by_benchmark_not_in_policy
policies_with_exemptions
status_all_time
status_since_last_assessment
check_status_by_benchmark_all_time
check_status_by_benchmark_since_last_assessment
content_stats
Returns
Response with stats requested.
Examples
Request

client.api.sec.get_stats()
Response
RPCResponse(
riq=4,
ret={
"policies_created": 2,
"policies_with_schedule": 0,
"remediation_jobs_run": 9,
"checks_by_benchmark": {"PCI-DSS-3.2": 44, "CCE": 81, "800-171": 76, "CIS-
˓→CentOS7": 223, "CIS-RHEL7": 222, "CIS": 182, "CIS-CentOS": 1, "CCE-Win16": 111,
˓→"CIS-RHEL": 1, "CIS_CentOS7": 1, "CIS_RHEL7": 1, "800-53": 68, "CIS-Win16": 34,
˓→"CIS-Win10": 31, "CCE-Win10": 95},
"status_all_time": {"compliant": 71830, "noncompliant": 85882, "notapplicable

˓→": 1414},
"content_stats": {

"uuid": "16386268-f2e1-4ab3-8e46-7f59131dee48",
"content_benchmarks": 7,
"success": true,
"db_benchmarks": 7,
"ingest_date": "2019-01-27T14:07:49.898504",
"content_checks": 437,
"db_checks": 437,
"errors": null
},
"checks_assessed_all_time": 226,
"checks_remediated_all_time": 226
},
error=None,
warnings=[])
delete_custom_checks(…)
Returns None.
Delete custom checks
Table 28.77: delete_custom_checks() parameters

check_uuids List of custom check UUIDs.
Returns
Returns nothing if the check was successfully deleted
Examples
Request

client.api.sec.delete_custom_checks(
check_uuids=["e912435e-2c38-4cfa-aa1e-985c83aa8a22"]
)
Response
RPCResponse(
riq=4,
ret={},
error=None,
warnings=[])

get_benchmarks(…)
Returns Dict.
Get information about benchmarks
Get information about one or more benchmarks.
Table 28.78: get_benchmarks() parameters

benchmark_uuid UUID of the benchmark.
policy_uuid List of benchmarks enabled within a given policy.
names List of benchmarks matching names.
os List of benchmarks applicable to specified OS.
authority_names List of benchmarks matching authority names such as
CIS, DISA STIGs.
type_name List of benchmarks matching type such as Unix, Win-
dows.
limit Maximim number of policies to return.
Returns
List of benchmarks matching specified criteria.
Examples
Request 1

client.api.sec.get_benchmarks()
Response 1
RPCResponse(
riq=4,
ret={
"count": 7,
"results": [
{
"uuid": "6b8ab80b-87a4-4f0c-8b6a-8bacf7c5853a",
"name": "CIS_CentOS_Linux_7_Benchmark_v2.2.0-1",
"display_name": "CIS CentOS Linux 7 Benchmark v2.2.0",
"version": "1",
"description": "Benchmark Description goes here",
"authority": "CIS",
"os": "None",
"type": "cis",
"dep_date": null,
"last_update": "2019-01-24T19:43:40.310324",

"user_flag": "None",
"policies": [
"b0714471-64cb-4446-a302-1e4ab6ec9cde"
]
}
]
},
error=None,
warnings=[])
Request 2

client.api.sec.get_benchmarks(
benchmark_uuid="6b8ab80b-87a4-4f0c-8b6a-8bacf7c5853a",
policy_uuid="b0714471-64cb-4446-a302-1e4ab6ec9cde"
)
Response 2
RPCResponse(
riq=4,
ret={
"count": 1,
"results": [
{
"uuid": "6b8ab80b-87a4-4f0c-8b6a-8bacf7c5853a",
"name": "CIS_CentOS_Linux_7_Benchmark_v2.2.0-1",
"display_name": "CIS CentOS Linux 7 Benchmark v2.2.0",
"version": "1",
"description": "Benchmark Description goes here",
"authority": "CIS",
"os": "None",
"type": "cis",
"dep_date": null,
"last_update": "2019-01-24T19:43:40.310324",
"user_flag": "None",
"policies": [
"b0714471-64cb-4446-a302-1e4ab6ec9cde"
]
}
]
},
error=None,
warnings=[])
get_stats_history(…)
Returns Dict.
Get statistics History for SecOps

Table 28.79: get_stats_history() parameters

since_time Filter results by time.
time_unit Unit of time to filter the results.
limit Maximum number of results to return.
Returns
Returns stats history.
Examples
Request

client.api.sec.get_stats_history(
since_time=7300,
time_unit="days"
)
Response
RPCResponse(
riq=4,
ret={
"results": [{
"uuid": "4db84e45-974f-4456-8125-57f7533f3d96",
"stats": {
"policies_created": 1,
"policies_with_schedule": 0,
"remediation_jobs_run": 1,
.
.
.
}
}]
},
error=None,
warnings=[])
get_policies(…)
Returns Dict.
Get summary information on known security policies.
Get information about configured policies.

Table 28.80: get_policies() parameters

policy_uuids List of security policy UUIDs. This parameter is op-
tional when retrieving a list of policies.
names List of security policy names. This parameter is op-
tional when retrieving a list of policies.
tgt_uuids List of security policy target group UUIDs. This pa-
rameter accepts one or more tgt_uuids.
include_stats Set to True to include stats in response. Set to False
by default.
limit Maximim number of policies to return.
Returns
List of policies matching the request criteria.
Examples
Request 1

client.api.sec.get_policies(
policy_uuids=[
"f768e864-b5c2-494f-a116-8c335edcb7bd",
"292372eb-ce12-4c6f-bbfc-bf916ba02649"
],
include_stats=True
)
Response 1
RPCResponse(
riq=4,
ret={
"count": 1,
"results": [
{
"uuid": "51f06de4-60ae-4cf3-83c1-65635941b4ba",
"name": "Oracle",
"tgt_uuid": "2b6bbf3d-b728-44de-8c4a-9e019fc50175",
"tgt_name": "OracleLinux",
"schedule_uuid": null,
"last_update": "2018-12-13T05:21:33.170597",
"last_assess_jid": "20181213052141677720",
"last_assess_timestamp": "2018-12-13T05:21:41.637187",
"last_remed_jid": "20181213052240095855",
"last_remed_timestamp": "2018-12-13T05:22:40.050577",

"schedule": null,
"variables": [
{
"check_uuid": null,
"var_name": null,
"var_value": null
}
],
"stats": {
"compliant": 2,
"noncompliant": 18
}
}
],
"check_count": 20,
"minion_count": 1
},
error=None,
warnings=[])
Request 2

client.api.sec.get_policies()
Response 2
RPCResponse(
riq=4,
ret={
"results": [
{
"last_remed_jid": null,
"name": "Security Policy",
"uuid": "fae4aa90-8e0c-4fda-b52b-b53ee0593f3e",
"last_assess_timestamp": null,
"tgt_uuid": "7f93b928-388b-11e6-b133-346895ecb8f3",
"stats": {
"unknown": 88
},
"schedule": null,
"variables": [
{
"var_name": null,
"var_value": null,
"check_uuid": null
}
],
"last_remed_timestamp": null,
"last_assess_jid": null,
"tgt_name": "All Minions",
"last_update": "2019-01-13T19:55:54.476425"

}
],
"check_count": 22,
"count": 1,
"minion_count": 0
},
error=None,
warnings=[])
save_exemption(…)
Returns Dict.
Add or update an exemption on a policy
Table 28.81: save_exemption() parameters

reason Reason for exemption.
check_uuids UUIDs of checks that are exempt.
minion_ids Minion IDs that are exempt.
Returns
Success or error code from saving exemption.
Examples
Request

client.api.sec.save_exemption(
policy_uuid="e912435e-2c38-4cfa-aa1e-985c83aa8a22",
reason="Approved by CISO",
minion_ids=[{"master1_master":["oracle"]}],
check_uuids=["70ceb294-0ce0-4144-8e8a-26301609cce1"]
)
Response
RPCResponse(
riq=4,
ret={
"count": 1,
"results": [{
"uuid": "3a776df3-9c4d-4d54-8e1f-dc0c189f0f68",
"policy_uuid": "e912435e-2c38-4cfa-aa1e-985c83aa8a22",
"check_uuid": "02b952e3-1d8c-4db3-8771-3edf23e0a0dd",
"master_id": "master1_master",

"minion_id": "oracle",
"reason": "Approved by CISO"
}]
},
error=None,
warnings=[])
delete_policy(…)
Returns bool.
Delete a existing security policy.
Table 28.82: delete_policy() parameters

policy_uuid UUID of the policy to delete.
Returns
Response code from deleting the policy.
Examples
Request

client.api.sec.delete_policy(
policy_uuid="db1ae70f-768e-4486-adae-b83546a09dea"
)
Response
RPCResponse(
riq=4,
ret=True,
error=None,
warnings=[])
get_checks(…)
Returns Dict.
Get information about checks
List information about checks

Table 28.83: get_checks() parameters

policy_uuid List of checks enabled within a given policy.
benchmark_uuids List of checks matching one or more benchmark
UUIDs.
user_flag Filter checks by user_flag ‘C’ - Custom ‘S’ - SaltStack
None - All
names List of checks matching names.
limit Maximim number of checks to return.
Returns
List of checks matching selected criteria.
Examples
Request

client.api.sec.get_checks(
benchmark_uuids=["6b8ab80b-87a4-4f0c-8b6a-8bacf7c5853a"]
)
Response
RPCResponse(
riq=4,
ret={
"count": 224,
"results": [
{
"uuid": "0c3df74e-d0ca-4c6e-9d2f-39035ff98f7a",
"name": "locke.system.file.at_cron_authorized_users",
"version": "1",
"display_name": "Ensure at/cron is restricted to authorized users",
"state_fs_uuid": "e78a934f-0355-4fc7-9d4c-3ccb1a5fcb79",
"mini_meta_fs_uuid": "16666977-7d8b-44bd-9cd3-909546673098",
.
.
.
}
]
},
error=None,
warnings=[])

save_policy(…)
Returns UUID.
Save a new security policy or update an existing one.
Saves a policy.
Table 28.84: save_policy() parameters

name Name of the security policy.
tgt_uuid UUID of the target group the security policy applies
to.
policy_uuid UUID of the security policy. This parameter is op-
tional when creating a new policy and required when
updating an existing policy.
benchmark_uuids Optional list of UUIDs of existing security policy
benchmarks to include in the policy. The policy will
include the checks from each benchmark in the list,
minus any passed in check_uuids.
check_uuids Optional list of security policy checks to include in
the policy. If benchmark_uuids is also given, the
policy will include only checks that appear in at least
one of the specified benchmarks.
exclude_check_uuids Optional list of security policy checks to exclude from
the policy. This is useful for omitting some checks
that would otherwise be included as part of the bench-
marks passed in benchmark_uuids.
variables Optional list of security policy check variables to ap-
ply to the policy. Each entry in the list is a dict con-
taining three entries: check_uuid (UUID of the
check the variable applies to), name (variable name),
and value (variable value).
schedule Optional dict defining schedule for running policy
assessment. For details on the schedule structure,
see the schedule parameter of the schedule.
save() RPC method.
Returns
UUID of the new or updated policy.
Examples
Request

client.api.sec.save_policy(
name="Policy 1",
tgt_uuid="919193da-604e-456d-87c4-90860f5e8b59",
benchmark_uuids=[
"22c8539e-f719-4d6a-9e14-c3c638a7be82",

"026e3afb-d4a7-45be-b405-4f83fa7a3b3a"
]
)
Return
RPCResponse(
riq=4,
ret="de301811-80d2-4a89-bd24-93d025347394",
error=None,
warnings=[])
Request

client.api.sec.save_policy(
name="Policy 2",
tgt_uuid="61edbf8c-8b5c-483c-845b-ff12280aa171",
benchmark_uuids=["4eec46a0-d029-4c3a-a8dd-c6cbb86b9659"],
check_uuids=[
"55c17549-095a-4dba-9817-0db845385eeb",
"985b5057-42c8-4c86-8c8e-06d8b3f51472",
"a2f200b6-6040-46bb-9005-9725e9b65490",
"c0df2e2d-13df-457a-bbca-cb0cbf495525"
],
variables=[{
"check_uuid": "985b5057-42c8-4c86-8c8e-06d8b3f51472",
"name": "_locke.system.service.sshd_maxauthtries.SSHD_CONFIG_MAXAUTHTRIES",
"value": "3"
}]
)
Response
RPCResponse(
riq=4,
ret="de301811-80d2-4a89-bd24-93d025347394",
error=None,
warnings=[])
get_check_minions(…)
Returns Dict.
Get minion-related information about checks

Table 28.85: get_check_minions() parameters

policy_uuid Policy UUID
check_uuid List information about a specific check UUID included
in a policy.
check_names List of checks with matching check names.
minion_ids List of minions matching minion-ids.
exempt Limit results to minions that are exempt (True) or non
exempt (False).
jid Filter results by assessment job id.
state Filter results by compliance state of the check or min-
ion.
action Filter results by compliance action, assess or remedi-
ate.
include_in_response Select the blocks of results that should appear in
the response. By default all results will appear
in response. Following list are acceptable results,
check_summary, minion_summary, check_stats,
minion_stats, check_report, check_exempt, over-
all_stats.
grains Grains to select, filter and sort by.
comment Filter results by assessment or remediation comment.
changes Filter results by assessment or remediation changes.
sort_by Sort by compliance states Compliant, Not Compliant,
Not Applicable, Error, and Unknown.
Response
Returns results matching criteria sent in the request.
Examples
Request

client.api.sec.get_check_minions(
policy_uuid="3c625016-9dbf-44d8-b97c-17f4361b78a0"
)
Response
RPCResponse(
riq=4,
ret={
"count": 3,

"results": [
{
"check_name": "locke.system.service.sshd_maxauthtries",
"check_display_name": "Ensure SSH MaxAuthTries is set to 4 or less",
"policy_uuid": "3c625016-9dbf-44d8-b97c-17f4361b78a0",
"policy_name": "SecOps",
"check_uuid": "80492e63-af0b-41c8-9a5b-b202be658561",
"check_version": "1",
.
.
.
}
]
},
error=None,
warnings=[])
remediate_policy(…)
Returns Dict.
Remediate one or more checks in a policy
Table 28.86: remediate_policy() parameters

policy_uuid UUID of the policy to remediate.
check_uuids Check UUIDs included in the policy to remediate.
minions Minions to remediate.
Response
Job ID for remediation run.
Examples
Request

client.api.sec.remediate_policy(
policy_uuid="3c625016-9dbf-44d8-b97c-17f4361b78a0",
minions={"master2_master":["master2"]},
check_uuids=["80492e63-af0b-41c8-9a5b-b202be658561"]
)
Response
RPCResponse(
riq=4,
ret={

"success": true,
"errors": [],
"jid": "20190125002727876899"
},
error=None,
warnings=[])
delete_exemption(…)
Returns Dict.
Delete an exemption
Table 28.87: delete_exemption() parameters

exemption_uuid UUID of the exemption.
Returns
Examples
Request

client.api.sec.delete_exemption(
exemption_uuid="3a776df3-9c4d-4d54-8e1f-dc0c189f0f68"
)
Response
RPCResponse(
riq=4,
ret={"uuid": "3a776df3-9c4d-4d54-8e1f-dc0c189f0f68"},
error=None,
warnings=[])
get_check_dependencies(…)
Returns Dict.
Get the dependencies for a check i.e. which policies and benchmarks reference it
Table 28.88: get_check_dependencies() parameters

check_uuid UUID of the custom check.

Returns
Returns the list of policies and benchmarks that reference this check
Examples
Request

client.api.sec.get_check_dependencies(
check_uuid="e912435e-2c38-4cfa-aa1e-985c83aa8a22"
)
Response
RPCResponse(
riq=4,
ret={
"policies": ["d3c68d55-04d7-4451-8f1e-f2b3e6d9ff3f", "b6da0147-2bbd-4497-b11b-
˓→b9f5548e7297"],
"benchmarks": ["563577e3-e84f-4204-a89b-8456df96c34f", "475a6070-56d5-49a0-

˓→840b-000efe8780e0"]
},
error=None,
warnings=[])
get_policy_run_history(…)
Returns Dict.
Get assessment and remediation runs against the policy
Table 28.89: get_policy_run_history() parameters

jid Job ID
fun Job function name.
state Filter by one or more statuses of the assessment or
remediation runs.
user Name of the user who ran the policy.
expected Number of expected minions to return a result.
returned Number of minions which returned a result.
Returns

Examples
Request

client.api.sec.get_policy_run_history(
policy_uuid="e912435e-2c38-4cfa-aa1e-985c83aa8a22"
)
Response
RPCResponse(
riq=4,
ret={
"count": 2,
"results": [{
"jid": "20190127194046350020",
"state": "completed_failures",
"fun": "policy.assessment",
"user": "root",
"expected": 8,
"returned": 8,
"returned_good": 5,
"returned_failed": 3,
"create_time": "2019-01-27T19:42:53.087028",
"user_uuid": "80c67364-cb31-4f4b-972a-e7ea3f752bb8",
"uuid": "e912435e-2c38-4cfa-aa1e-985c83aa8a22",
"name": "demo",
"last_update": "2019-01-27T19:40:40.544772",
"last_assess_jid": "20190127194046350020",
"last_remed_timestamp": null
}]
},
error=None,
warnings=[])
assess_policy(…)
Returns Dict.
Run assessment of checks in a policy
Table 28.90: assess_policy() parameters

policy_uuid Policy UUID to assess.

Response
Job ID for assessment run for specified policy.
Examples
Request

client.api.sec.assess_policy(
policy_uuid="1f90f261-1668-486e-a1d3-4dd68ef3020c"
)
Response
RPCResponse(
riq=4,
ret={
"success": true,
"errors": [],
"jid": "20190125001746553804"
},
error=None,
warnings=[])
ingest_custom_content(…)
Returns None.
Download Custom Content tarball :param hub: :param filename: :param content_type: application/x-gzip :param
blob: binary blob or base64 encoded :return: dict = { }
28.8.23 settings interface
RaaS settings RPC handler
save_auth_config(…)
Returns None.
Create or update the authentication configuration by the provided config_name.
Table 28.91: save_auth_config() parameters

config_name Name of the auth configuration
details Dictionary with details defining this authentication
configuration.
skip_job_scheduling If False, no scheduler jobs which maintain synchro-
nization with the Active Directory/LDAP backend are
created.

delete_auth_config(…)
Returns None.
Delete the authentication configuration by the provided name
Table 28.92: delete_auth_config() parameters

name The name of the authentication configuration to
delete.
save_auth_config_access(…)
Returns None.
Save access metadata for this authentication configuration.
Table 28.93: save_auth_config_access() parameters

config_uuid UUID referencing desired authentication configura-
tion.
get_directory_preview_records(…)
Returns None.
Return the records retrieved from the LDAP directory as collected so far. The return payload will contain the LDAP
records under the entries key as well as the status of the background job that is querying the directory. The status
will appear in the status key of the return payload.
get_auth_config(…)
Returns [‘Dict’, ‘List’].

Return the authentication configuration by the provided name, or all authentication configurations if name is not
specified.
Table 28.94: get_auth_config() parameters

config_name Name of the configuration to retrieve. Retrieve all if
config_name is None.
include_preview Include any auth_configs that are marked Preview.
Defaults to False. Only matters if config_name is
None, if a config_name is passed, always return the
config whether it is a preview config or not.
get_directory_preview_status(…)
Returns None.
Return a status for the background LDAP query job.

get_auth_config_access(…)
Returns Dict.
Return access metadata for this authentication configuration.
Table 28.95: get_auth_config_access() parameters

config_uuid UUID referencing desired authentication configura-
tion.
start_directory_preview(…)
Returns None.
Execute a background task that will return a set of example records from the defined LDAP or Active Directory.
Returns a task_id that can be used to check on the status of the preview. LDAP records are cached in Redis and can
be retrieved with get_directory_preview_records().
sync_auth_config(…)
Returns List.
Get updated information from the LDAP backend on users currently in use in SSE.
Table 28.96: sync_auth_config() parameters

config_name Name of the configuration to synchronize.
test_auth_config(…)
Returns Dict.
Test Active Directory/LDAP connectability and credentials for the provided authentication configuration details
Table 28.97: test_auth_config() parameters

details Connection details for the AD/LDAP backend.
Returns a dictionary with at least one key, validation_passed, for which the value is True or False depend-
ing on the outcome of the validation routines. If validation failed, an extra key, details is also included with an
explanation on what failed..
end_directory_preview(…)
Returns None.
Clears out the Redis cache entry for this particular preview job. This does not stop the background task, to stop a
background Celery task is somewhat ugly, we can revisit this later if it appears we really need to make sure the task
is dead.
28.8.24 stats interface
RPC stats endpoint

db_health(…)
Returns None.
Get database health status
null(…)
Returns None.
Null RPC method to test the fastest RPC Api response
get_queue_size(…)
Returns None.
Get Celery queue size
28.8.25 test interface
Test utilities
sleep(…)
Returns str.
Sleep for the amount of time provided.
Table 28.98: sleep() parameters

seconds Number of seconds to sleep. Float values permitted.
echo(…)
Returns str.
Echo the message.
Table 28.99: echo() parameters

message The message to echo.
warnings(…)
Returns bool.
Test how a warning is returned under the RPC Api.
error(…)
Returns bool.
Test how an error is returned under the RPC Api. Simply raises a generic exception.

28.8.26 tgt interface
Target groups RPC interface
delete_target_group(…)
Returns None.
Delete a target group.
Table 28.100: delete_target_group() parameters

tgt_uuid UUID referring to the target group to delete.
force Force deletion of target group and scheduled jobs de-
pending on it.
raises FailedResourceDependency The target group has one or more schedules that depend on it and
force is false. The details of the exception contain the results of get_schedules with the dependent
schedules.
save_target_group_access(…)
Returns typing.Union[bool, uuid.UUID].

Save the access metadata for a target group.
Table 28.101: save_target_group_access() parameters

tgt_uuid Save metadata for target group matching this UUID.
get_target_group_access(…)
Returns Dict.
Get the access metadata for a target group.
Table 28.102: get_target_group_access() parameters

tgt_uuid Retrieve metadata for target group matching this
UUID.
get_target_group_minions(…)
Returns Dict.
Get the set of minions that match a target group according to the currently cached minion data. Minions are keyed
by master:
Documentation on how targets work in SaltStack Enterprise are here: Minions and targets
Table 28.103: get_target_group_minions() parameters

tgt_uuid The UUID of the target group for which to resolve
minions.

save_target_group(…)
Returns str.
Create a new or update an existing target group.
Documentation on how targets work in SaltStack Enterprise are here: Minions and targets
Table 28.104: save_target_group() parameters

tgt Target dictionary. See below for example.
name Name of the target group
tgt_uuid UUID for the target group. If empty, generate a new
UUID. Otherwise tgt_uuid must point to an exist-
ing target group.
desc Text description of this target group.
pillar_uuids List of UUIDs referring to related pillar structures.
wait_for_match If True, block this call until the target group is suc-
cessfully constructed. This can take some time on
large RaaS installations. If False then return imme-
diately.
The tgt argument takes a dictionary that looks like

{<master_id or '*'>:
{u'tgt_type': <target type>,
u'tgt': <target string>}}
tgt_type is the type of target: glob, grain, grain_pcre, pillar, pillar_pcre, list, ipcidr, pcre,
or node.
tgt is the actual target. For glob this would be any string matching minion IDs and utilizing shell-globbing
characters (*, ?, [], etc).
For compound see Salt’s description of compound target indicators for a full explanation, but an overview is below:
Compound matchers allow very granular minion targeting using any of Salt’s matchers. The default matcher is a
glob match, just as with CLI and top file matching. To match using anything other than a glob, prefix the match
string with the appropriate letter from the table below, followed by an @ sign.
Let- Match Type Example Alt Delim-

ter iter?
G Grains glob G@os:Ubuntu Yes
E PCRE Minion E@web\d|\.(dev|qa|prod)\.loc No
ID
P Grains PCRE P@os:(RedHat|Fedora|CentOS) Yes
L List of minions [email protected], minion3.domain.com or No
bl*.domain.com
I Pillar glob I@pdata:foobar Yes
J Pillar PCRE J@pdata:^(foo|bar)$ Yes
S Subnet/IP ad- [email protected]/24 or [email protected] No
dress
R Range cluster R@%foo.bar No
Matchers can be joined using boolean and, or, and not operators.
Here is an example for creating a target group with a compound target:

wintgtresult = c.api.tgt.save_target_group(
name='Windows',
desc='Windows',
tgt={'*':{'tgt_type':'compound', 'tgt':'G@os_family:Windows'}})
save_target_group() example:
client.api.tgt.save_target_group(tgt={'SSE_master': {'tgt_type': 'grain', 'tgt':

˓→'G@kernel:Linux'}}, name='NewTestLinux')
Update existing target example:
client.api.tgt.save_target_group(tgt={'SSE_master': {'tgt_type': 'grain', 'tgt':

˓→'G@kernel:Linux'}}, name='Linux', tgt_uuid='f2ace00c-4fa0-11e6-88bc-080027a7289c',
˓→desc='newdescription')
get_target_group(…)
Returns Dict.
Retrieve details for a target group. For more on targets, see Minions and targets
Table 28.105: get_target_group() parameters

tgt_uuid Retrieve details for this target group.
master_id Retrieve details for master with this ID (not UUID).
pillar_uuid Retrieve target details associated with this pillar
(UUID).
name Search the target group name for this text.
desc Search the target group description for this text.
include_pillar_data Include attached pillar data in the return payload (de-
fault False).
sort_by Sort by this field, either ‘name’ or ‘desc’.
reverse Return results in the reverse order.
limit Limit maximum target groups to this number (default
50).
page Return target groups from this page (offset = page *
limit).
Use either tgt_uuid or master_id, but not both. If tgt_uuid is used, other filters are not applied.
get_target_group() example:
client.api.tgt.get_target_group()
The return payload is a dictionary with the following elements:
{
'count': 100, # total target group count
'results': [...] # target groups
}
Example:

client.api.tgt.get_target_group(tgt_uuid='7f93b928-388b-11e6-b133-346895ecb8f3')
RPCResponse(
riq=5,
ret= {
u'results': [
{u'name': u'All Minions',
u'tgt': {u'*':
{u'tgt_type': u'compound',
u'tgt': u'*'}},
u'uuid': u'7f93b928-388b-11e6-b133-346895ecb8f3',
u'pillars': [],
u'metadata': {u'auth':
{u'access':
{u'Superuser':
{u'write': False,
u'read': True,
u'discover': True,
u'delete': False},
u'Administrator':
{u'write': False,
u'read': True,
u'discover': True,
u'delete': False},
u'User':
{u'write': False,
u'read': True,
u'discover': True,
u'delete': False}},
u'owner':
{u'username': u'--<{internal-access}>--',
u'config_name': u'internal',
u'uuid': u'c74f8bee-5ead-453e-8c86-
˓→344a4780c053'}}},
u'desc': u''}],
u'count': 1,
u'limit': 1
},
u'error'= None,
u'warnings'= [])
28.8.27 vman interface
Vulnerability Management RPC interface
get_content_stats(…)
Returns dict.
Get the stats for the latest ingested content
Examples

Request

client.api.vman.get_content_stats()
Response
RPCResponse(
riq=4,
ret={
"creation_date": "2019-08-26T20:52:18.479319",
"file_name": "vman_2019-08-26T20:52:18.479319_e5b4970e-250f-4b4e-b7a5-
˓→53df6e1d0448.tar.gz.e",
"ingest_date": "2019-09-24T17:04:07.865149",
"uuid": "e5b4970e-250f-4b4e-b7a5-53df6e1d0448"
},
error=None,
warnings=[])
get_exemptions(…)
Returns Dict.
Get exemptions
Table 28.106: get_exemptions() parameters

exemption_uuid UUID of the exemption.
Returns
List of matching advisories (either by policy_uuid or exemption_id or both)
Examples
Request

client.api.vman.get_exemptions(
exemption_uuid="3a776df3-9c4d-4d54-8e1f-dc0c189f0f68"
)

Response
RPCResponse(
riq=4,
ret={
"count": 1,
"results": [{
"advisory_uuid": "02b952e3-1d8c-4db3-8771-3edf23e0a0dd",
}]
},
error=None,
warnings=[])
delete_exemption_group(…)
Returns int.
Delete a specific exemption group.
Table 28.107: delete_exemption_group() parameters

exemption_group_uuid UUID of a specific exemption group to delete.
Returns
Number of deleted exemption groups.
Examples
Request

client.api.vman.delete_exemption_group(
exemption_group_uuid="e912435e-2c38-4cfa-aa1e-985c83aa8a22",
)
Response
RPCResponse(
riq=4,
ret=1
},
error=None,
warnings=[])

get_advisory_minions(…)
Returns Dict.
Get assessment and remediation results for a policy
Table 28.108: get_advisory_minions() parameters

policy_uuid Get assessment and remediation results about this
policy.
advisory_id Limit results to advisories matching this advisory ID.
minion_id Limit results to minion matching one of this ID.
master_id Limit results to master matching one of this ID.
osfullname Limit results to OS matching name.
ipv4 Limit results to matching IPv4.
ipv6 Limit results to matching IPv6.
action Filter results by compliance action, assess or remedi-
ate.
include_in_response Choose the blocks that should appear in the response.
severity Filter results by severity.
advisory_title Filter results by partial advisory title match.
cve_id Filter results by partial CVE ID match.
pkg_name Filter results by partial package name match.
Examples
Request

client.api.vman.get_advisory_minions(
policy_uuid='26854b29-b122-4cc5-86ca-5d7ae3bdb107'
)
get_exemption_groups(…)
Returns Dict.
Get exemption groups.
An exemption group is a combination of minions and advisories that will not be remediated, with an associated
reason - perhaps your infrastructure requires an unsecure package, etc.
Table 28.109: get_exemption_groups() parameters

policy_uuid UUID of the associated policy.
exemption_group_uuid UUID of a specific exemption group to return.

Returns
List of exemptions groups for the policy.
Examples
Request

client.api.vman.get_exemption_groups(
)
Response
RPCResponse(
riq=4,
ret={
"count": 1,
"results": [{
"advisory_uuid": "02b952e3-1d8c-4db3-8771-3edf23e0a0dd",
}]
},
error=None,
warnings=[])
get_stats(…)
Returns Dict.
Get statistics for Vulnerability management policies
ping(…)
Returns bool.
Check if Vulnerability Management feature is available.
download_content(…)
Returns Dict.
Download and ingest content
Download Vulneraiblity management tarball and expand the files into hub.opts[‘cachedir’] + /vman Once the down-
load and expansion is complete, calls ingest to put them in the raas filesystem

get_policy_run_history(…)
Returns Dict.
Get assessment and remediation runs against the policy
Table 28.110: get_policy_run_history() parameters

jid Job ID
fun Job function name.
state Filter by one or more statuses of the assessment or
remediation runs.
user Name of the user who ran the policy.
expected Number of expected minions to return a result.
returned Number of minions which returned a result.
Returns
Examples
Request

client.api.vman.get_policy_run_history(
policy_uuid="e912435e-2c38-4cfa-aa1e-985c83aa8a22"
)
Response
RPCResponse(
riq=4,
ret={
"count": 2,
"results": [{
"jid": "20190127194046350020",
"state": "completed_failures",
"user": "root",
"expected": 8,
"returned": 8,
"returned_good": 5,
"returned_failed": 3,
"create_time": "2019-01-27T19:42:53.087028",
"user_uuid": "80c67364-cb31-4f4b-972a-e7ea3f752bb8",
"uuid": "e912435e-2c38-4cfa-aa1e-985c83aa8a22",
"name": "demo",

"last_update": "2019-01-27T19:40:40.544772",
"last_assess_jid": "20190127194046350020",
"last_remed_timestamp": null
}]
},
error=None,
warnings=[]
get_reports(…)
Returns Dict.
Get vulnerability summary reports
Table 28.111: get_reports() parameters

policy_uuid UUID of policy. Optional, when None, daily aggre-
gated reports are returned.
fun Filter by funciton, should be policy.assessment
or policy.remediate.
start_date Get reports on or after date.
end_date Get reports on or before date.
sort_by Sort on field, should be date only.
reverse Reverse list order. true or false.
page Page number, default is 0.
limit: Number of results
40.
returned. Default
Returns: List of reports
Examples
Request

client.api.vman.get_reports()
Response
RPCResponse(
riq=4,
ret={
"count": 1,
"results": [
{

"report_uuid": "53b79e83-1269-43fb-8e0f-f4d4c201df30",
"date": "2019-09-24",
"creation_date": "2019-09-24T17:11:57.449781",
"policy_uuid": "a5aa646e-f7fe-4d99-945b-7e40b929df7b",
"critical": 42,
"high": 104,
"medium": 136,
"low": 0,
"none": 0,
"policy_name": "awesome policy",
"target_group_name": "All Minions",
"top_advisories": [
{
"name": "systemd security, bug fix, and enhancement update",
"uuid": "b4c3b40a-9f11-42e4-8777-df541f20f816",
"score": 9.8,
"minions": 6
},
{
"name": "systemd security, bug fix, and enhancement update",
"uuid": "91a0b654-cb2b-48eb-b27c-b085fd035ffa",
"score": 9.8,
"minions": 6
},
{
"name": "perl security update",
"uuid": "4c4549b4-564a-446f-af0e-fd642df58dc8",
"score": 9.8,
"minions": 2
},
{
"name": "libssh2 security, bug fix, and enhancement update",
"uuid": "9acffe23-1344-4d0a-895b-e4cc63d4bcd3",
"score": 9.1,
"minions": 2
},
{
"name": "curl security and bug fix update",
"uuid": "7e3c8b03-38da-40a5-b0bf-e689216e3dda",
"score": 9.1,
"minions": 4
}
]
}
]
},
error=None,
warnings=[])
save_exemption_group(…)
Returns UUID.
Add or update an exemption on a policy

Table 28.112: save_exemption_group() parameters

reason Reason for exemption.
advisory_uuids UUIDs of checks that are exempt.
minion_ids Minion IDs that are exempt.
Returns
UUID of exemption group or error code from saving exemption.
Examples
Request

client.api.vman.save_exemption_group(
reason="Approved by CISO",
minion_ids=[{"master1_master":["oracle"]}],
advisory_uuids=["70ceb294-0ce0-4144-8e8a-26301609cce1"]
)
Response
RPCResponse(
riq=4,
ret="3a776df3-9c4d-4d54-8e1f-dc0c189f0f68",
error=None,
warnings=[])
get_stats_history(…)
Returns Dict.
Get statistics History for vulnerability management
Table 28.113: get_stats_history() parameters

since_time Filter results by time.
time_unit Unit of time to filter the results.

Returns
Returns stats history.
Examples
Request

client.api.vman.get_stats_history(
since_time=7300,
time_unit="days"
)
assess_policy(…)
Returns str.
Run assessment of advisories in a policy
Table 28.114: assess_policy() parameters

policy_uuid Policy UUID to assess.
Response
Job ID for assessment run for specified policy.
Examples
Request

client.api.vman.assess_policy(
policy_uuid="1f90f261-1668-486e-a1d3-4dd68ef3020c"
)
Response
RPCResponse(
riq=4,
ret={
"success": true,
"errors": [],
"jid": "20190125001746553804"
},

error=None,
warnings=[])
remediate_policy(…)
Returns str.
Remediate one or more advisories in a policy
Table 28.115: remediate_policy() parameters

policy_uuid UUID of the policy to remediate.
check_uuids Check UUIDs included in the policy to remediate.
minions Minions to remediate.
Response
Job ID for remediation run.
Examples
Request

client.api.vman.remediate_policy(
policy_uuid="3c625016-9dbf-44d8-b97c-17f4361b78a0",
minions={"master2_master":["master2"]},
check_uuids=["80492e63-af0b-41c8-9a5b-b202be658561"]
)
Response
RPCResponse(
riq=4,
ret={
"success": true,
"errors": [],
"jid": "20190125002727876899"
},
error=None,
warnings=[])
get_detail_report(…)
Returns None.
Get vulnerability detailed report

Table 28.116: get_detail_report() parameters

report_uuid UUID of report to retrieve.
Return: JSON formatted report.
Examples
Request

client.api.vman.get_detail_report(
report_uuid="1471bdbc-c495-4211-b6f0-6e442ce4dde6"
)
Response
RPCResponse(
riq=4,
ret={
"minions": {
"master2": [
{
"usage": {
"cmd": [],
"enabled": [],
"network": [],
"running": []
},
"comment": null,
"pkg_name": "glibc",
"severity": "medium",
"advisory_id": "CESA-2019:2118",
"master_uuid": "60522eca-8ad0-43fb-9461-171027e03deb",
"advisory_uuid": "082e07e7-6abd-4617-b4d9-0800091baa9b",
"pkg_version_target": "2.17-292.el7",
"pkg_version_current": "2.17-260.el7_6.6",
"pkg_version_advisory": "2.17-292.el7"
},
]
},
"advisories": {
"CESA-2016:1064": {
"info": {
"cve": {
"uuid": "027bc255-638b-409b-9e66-613538cc93c8",
"cve_id": "CVE-2016-2149",
"cvssv2": "AV:N/AC:L/Au:S/C:P/I:N/A:N",
"cvssv3": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"references": {
"REDHAT": {
"url": "https://access.redhat.com/errata/RHSA-
˓→2016:1064",

"name": "RHSA-2016:1064"
}
},
"cvssv2_base": 4.0,
"cvssv3_base": 6.5,
"description": "Red Hat OpenShift Enterprise 3.2 allows remote
˓→ authenticated users",
"published_date": "2016-06-08T17:59:00",
"cvssv2_severity": "MEDIUM",
"cvssv3_severity": "MEDIUM",
"cvssv2_impact_score": 2.9,
"cvssv3_impact_score": 2.9
},
"uuid": "18b865af-47ad-4786-8124-d0748a0bb1f2",
"title": "CentOS OpenShift Enterprise 3.2 security, bug fix, and
˓→enhancement update",
"packages": {
"el7": {
"kibana": "4.1.2-2.el7aos",
"lucene": "4.10.4.redhat_1-5.el7",
"rubygem-fluent-plugin-kubernetes_metadata_filter-doc":
˓→"0.12.0-1.el7aos"
}
},
"severity": "high",
"advisory_id": "CESA-2016:1064",
"description": "OpenShift Enterprise by Red Hat is the company's
˓→cloud computing Platform",
},
"minions": [
"master2"
]
},
},
"meta": {
"policy_uuid": "a5aa646e-f7fe-4d99-945b-7e40b929df7b",
"policy_name": "awesome policy",
"target_group_name": "All Minions",
"creation_date": "2019-09-24T17:11:57.449781",
"function": "policy.assessment",
"critical": 42,
"high": 104,
"medium": 136,
"low": 0,
"none": 0
}
},
error=None,
warnings=[])
get_policies(…)
Returns Dict.
Get summary information on vulnerability management policies

Table 28.117: get_policies() parameters

policy_uuids List of vulnerability management policy UUIDs. This
parameter is optional when retrieving a list of poli-
cies.
names List of vulnerability management policy names. This
parameter is optional when retrieving a list of poli-
cies.
tgt_uuids List of policy target group UUIDs. This parameter ac-
cepts one or more tgt_uuids.
limit Maximum number of policies to return.
Returns
List of policies matching the request criteria.
Examples
Request 1

client.api.vman.get_policies(
policy_uuids=[
"a5aa646e-f7fe-4d99-945b-7e40b929df7b",
],
)
Response 1
RPCResponse(
riq=4,
ret={
"count": 1,
"results": [
{
"uuid": "a5aa646e-f7fe-4d99-945b-7e40b929df7b",
"name": "awesome policy",
"tgt_name": "All Minions",
"last_update": "2019-07-18T19:55:05.617862",
"last_assess_jid": "20190719154009438906",
"last_remed_timestamp": null,
"stats": {
"CRITICAL": 1

},
"schedule": null,
"minions_assessed": 4
}
]
},
error=None,
warnings=[])
save_policy(…)
Returns UUID.
Save a new vulnerability management policy or update an existing one.
Table 28.118: save_policy() parameters

name Name of the vulnerability management policy.
tgt_uuid UUID of the target group the policy applies to.
policy_uuid UUID of the policy. This parameter is optional when
creating a new policy and required when updating an
existing policy.
schedule Optional dict defining schedule for running policy
assessment. For details on the schedule structure,
see the schedule parameter of the schedule.
save() RPC method.
Returns
UUID of the new or updated policy.
Examples
Request

client.api.vman.save_policy(
name="Policy 1",
tgt_uuid="919193da-604e-456d-87c4-90860f5e8b59",
)
Return
RPCResponse(
riq=4,
ret="de301811-80d2-4a89-bd24-93d025347394",
error=None,
warnings=[])

delete_policy(…)
Returns bool.
Delete an existing vulnerability management policy.
Table 28.119: delete_policy() parameters

policy_uuid UUID of the policy to delete.
Returns
Response code from deleting the policy.
Examples
Request

client.api.vman.delete_policy(
policy_uuid="db1ae70f-768e-4486-adae-b83546a09dea"
)
Response
RPCResponse(
riq=4,
ret=True,
error=None,
warnings=[])

CHAPTER
TWENTYNINE
TROUBLESHOOTING
29.1 Pages not Loading
If a page or section of a page fails to load, clicking the Reload button that appears on some pages or clicking the
browser refresh button often fixes the issue.
You might also encounter situations where a lack of permissions is also causing pages or page elements to not load
correctly. The following issues are often caused by insufficient permissions:
• Error loading users
• Blank roles page
• Blank file system page
• A red X after clicking Add on the Pillar page
If you encounter one of these issues, contact a Salt administrator to verify that your role membership and role
privileges are set correctly.
29.2 Some Minions Are Not Running Jobs
If some connected Salt minions are not returning job results, verify that the Salt minion key is accepted. Salt minions
that have unaccepted keys do not show presence or grains in the Targets workspace. You can view the Key State
report for all minions for detailed key status.
29.3 Job Results Take a Few Minutes to Display
Salt masters do not use a persistent connection to Enterprise API, instead the Salt master connects to the Enterprise
API at defined intervals to check for jobs. This means that it can take up to the max interval amount for the Salt
master to receive the job before execution starts.
29.4 Button Labels are Truncated
If button label text is partially cut off, or if the Graphic User Interface is otherwise not displaying correctly, make
sure you are using the latest version of one of the following web browsers.
• Google Chrome
• Mozilla Firefox
227
29.5 Generate a Bug Report
To assist SaltStack support, you can download a report that contains the previous 200 actions that you performed in
the current session from the help menu. If you have admin privileges, the previous 1000 entries are retrieved from
the Enterprise API and are also included in the bug report.
To download a bug report:
1. Refresh the browser.
2. (Optional, Admins only) Click the help icon in the top right corner and select Reset Server Stats.
3. Reproduce the issue using as few steps as possible. If the issue is not consistently reproducible, download the
bug report immediately after the issue occurs.
4. Click the help icon in the top-right corner and click Download Bug Report.
5. (Optional) Review the data that is contained in the log. Usernames and passwords are not logged.
6. Deliver the log to SaltStack support.
The Enterprise Console bug report information is stored locally in the browser, and is reset each session.
29.6 Additional Troubleshooting
Additional troubleshooting information might be available in the SaltStack Enterprise Knowledgebase at https://
support.saltstack.com.
228 Chapter 29. Troubleshooting

SaltStackEnterpriseHelp-V6 1 0 October

Uploaded by

Copyright:

Available Formats

SaltStackEnterpriseHelp-V6 1 0 October

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SaltStackEnterpriseHelp-V6 1 0 October

Uploaded by

Copyright:

Available Formats

SaltStack Enterprise Documentation

October 30, 2019 at 11:56:13 MDT

4 Minions and targets 13

13 Roles and Permissions 63

15 Built-in roles default settings 77

20 SecOps Compliance Custom Content 101

21 SecOps Vulnerability 109

22 SecOps Architecture 117

23 SaltStack Enterprise Configuration 119

24 Master Plugin 121

25 Configuration file example 125

27 Security Guidelines 137

28 Enterprise API (eAPI) RPC Endpoint Documentation 139

4 Chapter 1. SaltStack Enterprise

SaltStack Enterprise’s primary components are described in detail below.

2.1.1 Enterprise API

Role Based Access Control (RBAC)

For more on RBAC, see Roles and permissions.

2.1.4 Temporary data storage

2.1.5 Enterprise Console

For more on Enterprise Console, see Enterprise Console.

2.1.6 Salt Master Plugin

Job system architecture

The job system architecture is described in detail below.

2.2 See also

3.2 How to use Enterprise Console

3.2.1 Accessing Enterprise Console

3.2.2 Adjusting your preferences

3.2.3 Changing your password

3.2.4 Opening product documentation

The documentation opens in a new tab.

3.3.1 Supported web browsers

3.3.2 User preferences

Under Preferences, you can adjust the following options:

10 Chapter 3. Enterprise Console

Note: SecOps Compliance is an add-on to SaltStack Enterprise, and a license is required.

3.4 See also

• Introduction to SaltStack Enterprise

3.4. See also 11

12 Chapter 3. Enterprise Console

MINIONS AND TARGETS

4.2 How to use minions and targets

4.2.1 Viewing minion details

1. In the Minions workspace, select a minion ID from the id column.

Downloading minion data

Searching for a minion

Changing table columns

1. Click the Column button in the lower left corner.

4.2.2 Running a job

14 Chapter 4. Minions and targets

2. Click Run job.

4. Select additional options as needed and click Run now.

4.2.3 Running a command

4.2. How to use minions and targets 15

4.2.4 Defining a new target

1. In the Minions workspace, click Create target.

3. When complete, click Save.

Defining a simple list target

16 Chapter 4. Minions and targets

The selected list is included as a criterion.