How do I define user roles

With the SaltStack Config Role Based Access Control (RBAC) system, you can define permission settings for multiple users at once, as permission settings for a role apply to all users included in the role. You can define these settings in the Roles workspace in the user interface.

SaltStack Config ships with many built-in roles that cannot be deleted.

• User - The default role assigned to all new local users, SSO, 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.
• Administrator - This role needs access to more advanced tools than the user role and thus can access System Administration. 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.
• Superuser - Superusers can perform any operation in SaltStack Config, which includes accessing System Administration. 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.

Additionally, you can create custom-defined roles for your organization’s unique needs.

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.

Resource access for certain resource types and functional areas must be defined in the API (RaaS), rather than the Roles editor.

After creating a role, you can choose to clone it, set permitted tasks, and assign access to a job or target.

To define a role for role-based access controls (RBAC) in SaltStack Config, you must both define the permitted task and also assign resource access. A task is a specific operation that can be performed in the user interface, such a creating, editing, or running a job. A resource is an element of your environment, such specific masters, minions, targets, file data, etc.

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.

In this example, a role can run test.ping on the Linux target group with these permissions settings:

• Read access to the Linux target
• Read/Run access to a job that includes the test.ping command

Tasks

The Tasks tab includes the following options.

Task	Description
Create and delete new targets	Role can create new targets. Users assigned to this role can edit and delete targets they have created, or other targets defined under Resource Access. A target is the group of minions, across one or many Salt masters, that a job’s Salt command applies to. A Salt master can also be managed like a minion and can be a target if it is running the minion service. See How do I create Targets.
Modify pillar data	Role can view, edit, and delete sensitive information stored in pillars. Users belonging 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 the API (RaaS) 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. See How do I create state files and pillar data.
Modify file server	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 the API (RaaS) 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. See How do I create state files and pillar data.
Run arbitrary commands on minions	Role can trigger commands outside of a job for the Salt master to pick up. Role is not limited to running only commands included in a given job’s definition. Minions are nodes running the minion service, which can listen to commands from a Salt master and perform the requested tasks.
Accept, delete, and reject keys	Role can accept, delete, and reject minion keys as needed for initial configuration. A minion key allows encrypted communication between a Salt master and Salt minion.
Read and modify users, roles, permissions	Role can view users and associated data, as well as edit roles and permissions settings. 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 masters	Role can run commands on Salt masters, such as to run orchestration. Commands run against the Salt master are also called Salt runners. Salt runners are modules used to execute convenience functions on the Salt master. See How do I create jobs. Adding this permission allows the role to be able to use the salt-run option from the Run command feature under the Minions tab.
Compliance - create, edit, delete, and assess	Role can create, edit, delete, and assess SaltStack SecOps Compliance policies. In 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 OracleLinuxAdmin role to define policies for an OracleLinux target, you would assign the role both permission to complete this task, and Read access to the OracleLinux target. This task does not allow the role to remediate SaltStack SecOps Compliance policies. SaltStack SecOps Compliance is an add-on to SaltStack Config that manages the security compliance posture for all the systems in your environment. See Using and Managing SaltStack SecOps for more information. Note: A SaltStack SecOps license is required.
Compliance - remediate	Role can remediate any non-compliant minions detected in a SaltStack SecOps Compliance assessment. SaltStack SecOps Compliance is an add-on to SaltStack Config that manages the security compliance posture for all the systems in your environment. See Using and Managing SaltStack SecOps for more information. Note: A SaltStack SecOps license is required.
Compliance - update SaltStack content	Role can download updates to the SaltStack SecOps Compliance security library.
Vulnerability - create, edit, delete, and assess	Role can create, edit, delete, and assess SaltStack SecOps Vulnerability policies. In addition 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 SaltStack SecOps Vulnerability policies. SaltStack SecOps Compliance is an add-on to SaltStack Config that manages the security compliance posture for all the systems in your environment. See Using and Managing SaltStack SecOps for more information. Note: A SaltStack SecOps license is required.
Vulnerability - remediate	Role can remediate vulnerabilities detected in a SaltStack SecOps Vulnerability assessment. SaltStack SecOps Vulnerability is an add-on to SaltStack Config that manages vulnerabilities on all the systems in your environment. See Using and Managing SaltStack SecOps for more information. Note: A SaltStack SecOps license is required.

Resource Access

The Resource Access tab allows you to define resource access for targets and jobs. A target is the group of minions, across one or many Salt masters, that a job’s Salt command applies to. A Salt master can also be managed like a minion and can be a target if it is running the minion service. Jobs are used to run remote execution tasks, apply states, and start Salt runners.

Note: Resouces types not defined in the table do not require any specific resource access settings.

Resource Type	Access Levels
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.
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.
Other Resouce types - access to these resource types must be defined using the API (RaaS) Files in the file server Pillar data Authentication configuration	Defined in the API (RaaS)

To create and define a role:

Prerequisites

To define user roles, you must have administrator access.

Procedure

1. From the side menu, click Administration > Roles.
2. Click Create and enter a name for your role.
3. Under Tasks, select permitted actions to grant for the role.
4. Click Save.
5. To assign access to a job or target, select the role from the Roles workspace, locate the required job or target under Resource Access, and select the access level desired. For example, to allow a role to run jobs, select Read/Run, and click Save.
6. (Optional) To include groups, select the role from the Roles workspace, select the groups you want to include from Groups, and click Save.
   Note: Role permissions are additive. Users in groups assigned to multiple roles receive access to a combination of all items granted from each role. The selected groups, including all users in those groups, are granted all permitted tasks and resource access defined in the role settings.
7. (Optional)To clone a role select the role from the Roles workspace, click Clone, enter a new name for the role, and click Save.
   Note: Cloned roles inherit permitted tasks from the original role by default. Cloned roles do not inherit resource access, which must be defined separately.
8. (Optional) In some situations you may need to configure more granular permissions. To grant Advanced permissions, click Administration > Roles > Advanced, select the role and select/deselect additional permissions. Click Save. For more information on Advanced permission and item types see Advanced permission and item types.
   Note: The minimum recommended permissions for typical user operations are highlighted in blue.