How do I define user roles

With the Tanzu Salt 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.

To define user roles, you must have administrator access.

Tanzu Salt 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 Tanzu Salt, which includes accessing System Administration and accepting master keys. 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 Tanzu Salt, 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. Note: Tanzu Salt does not support using this permission to limit roles to only creating targets within a specific group of minions. This permission allows users to create any target they choose.
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 minion 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. The Superuser role is required to accept minion keys.
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 in the Targets workspace.
Compliance - create, edit, delete, and assess	Role can create, edit, delete, and assess Tanzu Salt Compliance Cloud 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 OracleLinuxAdmin target, you would assign the role both permission to complete this task, and Read access to the OracleLinuxAdmin target. This task does not allow the role to remediate Tanzu Salt Compliance Cloud policies.
Compliance - remediate	Role can remediate any non-compliant minions detected in a Tanzu Salt Compliance Cloud assessment.
Compliance - update Tanzu Salt content	Role can download updates to the Tanzu Salt Compliance Cloud security library.
Vulnerability - create, edit, delete, and assess	Role can create, edit, delete, and assess Tanzu Salt Vulnerability Cloud 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 Tanzu Salt Vulnerability Cloud policies.
Vulnerability - remediate	Role can remediate vulnerabilities detected in a Tanzu Salt Vulnerability Cloud assessment.

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:
Resource 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 See How do I create jobs for more information.
Other Resource 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)

Define user roles

To define user roles, you must have administrator access.

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