In the realm of IT automation, being able to have precise control over who can access what can be a game changer. VMware Aria Automation Orchestrator takes this seriously with new emphasis on user roles and group permissions.
Here is a closer look at how these features are set up and why they matter.
Roles: The Gatekeepers of Access
Roles in Automation Orchestrator define what users can and cannot do within the client interface. These roles are your gatekeepers, regulating access to various features and content. However, the availability of role management features depends on your license type. Here is how it breaks down:
vSphere License: Sadly, the vSphere licenses do not support role management. The groups that fall under the vSphere license only have permission to “Run.”
VMware Aria Automation License: You may manage the roles directly in Automation Orchestrator Client with this license. This then means that you can assign the responsibility of managing and controlling what users can access in the system. Should you require more information, the roles are further managed by VMware Aria Automation Identity and Access Management.
| License | Authentication | |
|---|---|---|
| vSphere | VMware Aria Automation | |
| vSphere | Role management is not supported. Groups support only Run permissions. | |
| VMware Aria Automation | Manage roles in the Automation Orchestrator Client.See Assign Roles in the Automation Orchestrator Client. | Manage roles through Identity and Access Management in VMware Aria Automation.See Configure Automation Orchestrator Client Roles in VMware Aria Automation. |
Group Permissions: Grade Control to Content
Group permissions, on the other hand, get into the nitty gritties of the content access within the Automation Orchestrator Client. This includes workflows, actions, policies, elements of configuration, and resource elements. Keep in mind this essential note: standard workflows and actions available on the preconfigured system are common to all users unless you have configured otherwise using group permissions.
Administrator and Viewer roles: These make up the big wigs. They have access to all features and contents fully, irrespective of the group permissions setting. System Administrators create user roles, manage user group assignments, and then create groups and delete them.
Workflow Designer role: The users actually have access to view system content, create, run, edit, delete their content and add also their content in groups. They can run group content but cannot edit them. Please note that this role is not available for Orchestrator instances authenticated with vSphere.
Users with no Assigned Role: These users do not have an assigned role and therefore receive minimal permissions. They can only see their own runs, respond to requests for the interaction of user’s run, and if such activity is a group, it allows the owner of the run to view and run its contents groups. But to build, make changes or add content, the users should be assigned a Workflow Designer role.
Why It’s Important
| Role | Access Rights | ||
|---|---|---|---|
| Administrator | Administrators can access all Automation Orchestrator Client features and content, including the content created by specific groups. Responsible for setting user roles, creating and deleting groups, and adding users to groups. Administrators are not limited by group permissions.Tenant administrators from VMware Aria Automation environments used to authenticate Automation Orchestrator have Administrator rights by default. | ||
| Viewer | Viewers have read-only access to all content in the Automation Orchestrator Client, but cannot create, edit, run, or export content. Viewers can also see all groups and group content. Viewers are not limited by group permissions.The Viewer role overwrites the Workflow Designer role when set to the same user account. | ||
| No assigned group | Run | Run and edit | |
| Workflow Designer | View system content.View and run own runs.Create, run, edit, and delete own content. | View system contentView and run own runs.Create, run, edit, and delete own content.Add own content to the group.Run group content, but cannot edit it. | View system content.View and run own runs.Create, run, edit, and delete own content.Add own content to the group.Run and edit group content.Not available for Automation Orchestrator instances authenticated with vSphere. |
| User without an assigned role | View own runs.Respond to user interaction requests.These access rights are granted by default to users in VMware Aria Automation and vSphere without an assigned Automation Orchestrator role and group. | View and run own runs.View and run group content. | View and run own runs.View and run group content.To be able to create, edit, and add content, users in this group must be assigned a Workflow Designer role.Not available for Automation Orchestrator instances authenticated with vSphere. |
The user roles along group permissions in Automation Orchestrator come in handy as the preciseness defines their importance. You can categorize users into particular projects, so they access content only relevant to their group. For instance, you could have a group for users developing a particular project on the custom Automation Orchestrator plug-in. They can focus on what matters to them without interfering with content outside their group.
Generally, user roles and group permissions offered by Automation Orchestrator are essential in keeping a clean, safe, and an effective IT automation environment since they let the users retain control of the workflows but still give other teams access to the workflows whenever there is a need to ensure successful completion of the assigned activities.
Stay tuned for more insights and tech tips!