Description:
We want to integrate multiple clouds, for example 1 azure and 3 VMware vCenters in our Morpheus portal (same tenant). We want to separate the tasks and workflow between the individual clouds so that the end user cannot see the workflows on VMware and vice versa from Azure.
Example/Use case(s):
Let’s assume that an end user has access to 3 large environments - Azure, Private cloud and On-prem (VMWare), when requesting a new VM, he/she can choose where this server will be build, so far there is no problem… Once the server is created there are multiple workflows and tasks that the end user can perform/execute.
The goal is workflows and tasks to be used for the correct cloud and respectively to be hidden from the UI when users are in the scope of the VM and the corresponding cloud.
To separate the tasks and workflows between different clouds in a single tenant in Morpheus, you can leverage the cloud-specific workflows and task sets. Here’s a general approach you can follow:
Cloud-Specific Workflows: Morpheus allows you to create cloud-specific workflows. When creating a new workflow, you can specify the cloud(s) for which the workflow should be available. This way, you can create separate workflows for Azure, VMware vCenter, and other clouds you have integrated.
Task Sets: Task sets in Morpheus are a collection of tasks that can be performed on instances. You can create different task sets for different clouds, ensuring that the tasks are relevant to the specific cloud environment.
Instance Mapping: Once you have created cloud-specific workflows and task sets, you need to map them to the appropriate instances. This can be done during the provisioning process or by editing the instance details after provisioning.
User Access Control: Depending on your user access and permission model, you can control which users or user groups have access to specific clouds, workflows, and task sets. This way, you can restrict visibility and access to workflows and tasks based on the user’s scope and permissions.
Here’s an example of how you can implement this:
Create a workflow named “Azure Workflow” and specify that it should be available only for the Azure cloud.
Create another workflow named “VMware Workflow” and specify that it should be available only for the VMware vCenter cloud(s).
Create task sets for Azure and VMware vCenter, respectively, with tasks specific to each cloud environment.
During the provisioning process or by editing instance details, map the Azure instances to the “Azure Workflow” and the Azure task set, and map the VMware instances to the “VMware Workflow” and the VMware task set.
Configure user access and permissions to ensure that users only have access to the clouds, workflows, and task sets they should be able to see and use.
By following this approach, you can effectively separate the tasks and workflows between different clouds in a single tenant. End users will only see and interact with the workflows and tasks relevant to the cloud they are working with, providing a seamless and organized experience.
Please Note that the specific steps and configurations may vary depending on your Morpheus version and setup. It’s recommended to consult the Morpheus documentation or reach out to support for detailed guidance on implementing this solution in your environment.
To be honest, this answer shocks me a little… it’s obviously an unmodified answer from ChatGPT which unfortunately contains obvious errors.
Workflow do not offer the possibility to assign them to a specific cloud when creating them.
Likewise, there are no task sets in Morpheus.
The RBAC system of Morpheus should be used to tackle the described problem.
It is possible to give each role specific access rights to tasks and workflows.
For example, you could create two Morpheus resource groups. One has access to the azure cloud, the other has access to the VMware clouds. Then you can create two roles. One has access to the azure group and its specific workflows, the other to the VMware group and its workflows.
I know the ask here is about what the user can see, but if we step back a bit and automate as we can, user should not need to choose anything, because layouts are designed to handle the different clouds we need to provision to. We can attach our automations there.
