How do I define user roles
With the
Automation 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.To define user roles, you must have administrator access.
Going forward,
Automation Config
is no longer included in the Aria Automation suite of products. The new name of this product is VMware Tanzu Salt and this product is available as part of the VMware Tanzu Platform suite of products. See Using and Managing Tanzu Salt for more information.Automation 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 inAutomation Config, which includes accessing System Administration and accepting master keys.rootis 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
Automation 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 thetest.pingcommand
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?. Automation Config 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 Automation per Secure Hosts 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 Automation per Secure Hosts Compliance policies.Automation per Secure Hosts Compliance is an add-on toAutomation Config that manages the security compliance posture for all the systems in your environment. See Using and Managing Secure Hosts for more information.A Automation per Secure Hosts license is required. |
Compliance - remediate | Role can remediate any non-compliant minions detected in a Automation per Secure Hosts Compliance assessment.Automation per Secure Hosts Compliance is an add-on toAutomation Config that manages the security compliance posture for all the systems in your environment. See Using and Managing Secure Hosts for more information.A Automation per Secure Hosts license is required. |
Compliance - update Automation Config content | Role can download updates to the Automation per Secure Hosts Compliance security library. |
Vulnerability - create, edit, delete, and assess | Role can create, edit, delete, and assess Automation per Secure Hosts Vulnerabily 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 Automation per Secure Hosts Vulnerabily policies.Automation per Secure Hosts Compliance is an add-on toAutomation Config that manages the security compliance posture for all the systems in your environment. See Using and Managing Secure Hosts for more information.A Automation per Secure Hosts license is required. |
Vulnerability - remediate | Role can remediate vulnerabilities detected in a Automation per Secure Hosts Vulnerabily assessment.Automation per Secure Hosts Compliance is an add-on toAutomation Config that manages the security compliance posture for all the systems in your environment. See Using and Managing Secure Hosts for more information.A Automation per Secure Hosts 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.Resource types not defined in the table do not require any specific resource access settings.
Resource Type | Access Levels |
|---|---|
Targets |
|
Jobs |
Per ulteriori informazioni, vedere Come creare processi. |
Other Resouce types - access to these resource types must be defined using the API (RaaS)
| Defined in the API (RaaS) |
- From the side menu, click .
- ClickCreateand enter a name for your role.
- UnderTasks, select permitted actions to grant for the role.
- ClickSave.
- To assign access to a job or target, select the role from the Roles workspace, locate the required job or target underResource Access, and select the access level desired. For example, to allow a role to run jobs, selectRead/Run, and clickSave.
- (Optional) To include groups, select the role from the Roles workspace, select the groups you want to include fromGroups, and clickSave.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.
- (Optional) To clone a role select the role from the Roles workspace, clickClone, enter a new name for the role, and clickSave.Cloned roles inherit permitted tasks from the original role by default. Cloned roles do not inherit resource access, which must be defined separately.
- (Optional) In some situations you may need to configure more granular permissions. To grant Advanced permissions, click , select the role and select or deselect additional permissions. ClickSave. For more information on Advanced permission and item types see Advanced permission and item types.The minimum recommended permissions for typical user operations are highlighted in blue.
