As a cloud administrator, you want to control the tasks that your users can perform in vRealize Automation. Depending on your management goals and application development team responsibilities, there are different ways that you can configure the user roles to support those goals.
The following Cloud Assembly and Service Broker examples are based on three use cases. These examples provide only enough instruction to illustrate the application of users roles.
The target audience for these use cases is the cloud administrator, who is also considered the cloud administrator, and the service administrators.
The use cases build on each other. If you are ready to go directly to use case 3, you might need to review use cases 1 and 2 to better understand why you configure the roles in the ways specified.
The purpose of the use cases is to demonstrate user roles, not to provide detailed information about configuring your infrastructure, managing projects, creating cloud templates, and working with deployments.
Before you begin, you must understand the levels of user roles that are configured by a cloud administrator in the vRealize Automation Console.
- Organization Roles
The organization roles control who can access the console.
As an organization owner, you must ensure that all users of any of the services are assigned at least an organization member role.
Role Description Organization Owner An administrator can add users, change the role of users, and remove users from the organization. The owner manages which services users have access to. Organization Member A general user can log in to the organization console. To access the services, an organization owner must assign the users service roles. - Service Roles
The service roles control who can access their assigned services.
As an organization owner, you must ensure that the users who need access to the services are assigned the appropriate role. You use the roles to control how much the user can do in each service.
Table 1. Cloud Assembly Service Role Descriptions Role Description Cloud Assembly Administrator A user who has read and write access to the entire user interface and API resources. This is the only user role that can see and do everything, including add cloud accounts, create new projects, and assign a project administrator. Cloud Assembly User A user who does not have the Cloud Assembly Administrator role. In a Cloud Assembly project, the administrator adds users to projects as project members, administrators, or viewers. The administrator can also add a project administrator.
Cloud Assembly Viewer A user who has read access to see information but cannot create, update, or delete values. This is a read-only role across all projects in all the services. Users with the viewer role can see all the information that is available to the administrator. They cannot take any action unless you make them a project administrator or a project member. If the user is affiliated with a project, they have the permissions related to the role. The project viewer would not extend their permissions the way that the administrator or member role does.
Table 2. Service Broker Service Role Descriptions Role Description Service Broker Administrator Must have read and write access to the entire user interface and API resources. This is the only user role that can perform all tasks, including creating a new project and assigning a project administrator. Service Broker User Any user who does not have the Service Broker Administrator role. In a Service Broker project, the administrator adds users to projects as project members, administrators, or viewers. The administrator can also add a project administrator.
Service Broker Viewer A user who has read access to see information but cannot create, update, or delete values. This is a read-only role across all projects in all the services. Users with the viewer role can see all the information that is available to the administrator. They cannot take any action unless you make them a project administrator or a project member. If the user is affiliated with a project, they have the permissions related to the role. The project viewer would not extend their permissions the way that the administrator or member role does.
Table 3. Code Stream Service Role Descriptions Role Description Code Stream Administrator A user who has read and write access to the entire user interface and API resources. This is the only user role that can see and do everything, including create projects, integrate endpoints, add triggers, create pipelines and custom dashboards, mark endpoints and variables as restricted resources, run pipelines that use restricted resources, and request that pipelines be published in Service Broker. Code Stream Developer A user who can work with pipelines, but cannot work with restricted endpoints or variables. If a pipeline includes a restricted endpoint or variable, this user must obtain approval on the pipeline task that uses the restricted endpoint or variable. Code Stream Executor A user who can run pipelines and approve or reject user operation tasks. This user can resume, pause, and cancel pipeline executions, but cannot modify pipelines. Code Stream User A user who can access Code Stream, but does not have any other privileges in Code Stream. Code Stream Viewer A user who has read access to see pipelines, endpoints, pipeline executions, and dashboards, but cannot create, update, or delete them. A user who also has the Service viewer role can see all the information that is available to the administrator. They cannot take any action unless you make them a project administrator or a project member. If the user is affiliated with a project, they have the permissions related to the role. The project viewer would not extend their permissions the way that the administrator or member role does. - Project membership roles
The project membership determines what infrastructure resources and cloud templates are available.
Project membership is defined in the service by a user with a service administrator role. The service administrator must ensure that the users who need access to one or more projects are assigned the appropriate project role in each project.
Table 4. Project Roles Role Description Project Administrator A project administrator can manage their own projects, create and deploy cloud templates associated with their projects, and manage project deployments for all project members. Project Member A project member can create and deploy cloud templates associated with their projects, manage their own deployments, and manage any shared deployments. Project Viewer A project viewer is a member of the project with read-only access to their project resources, cloud templates, and deployments. - Custom roles
The custom roles are created by the Cloud Assembly to refine the member and viewer roles.
The procedures provided in these use cases are meant to highlight the user roles. They are not detailed or definitive procedures for setting up vRealize Automation.
As you configure roles, remember that users who are running API operations are subject to the roles that you assign here.
Prerequisites
- Verify that you have the Organization Owner role. You must see the Identity and Access Management tab with you log in to the console. If not, contact the organization owner.
- Verify that you have the service administrator role for the various services. If you are not certain about your role, contact the organization owner.
- Verify that your users are added to vRealize Automation.
When you install vRealize Automation, your Active Directory users are added as part of the process.
- For a more detailed task and role list for various roles, see Organization and service user roles in vRealize Automation.
