With the latest feature release in October 2019, vRealize Automation Cloud users can configure projects for project level deployment sharing, or for deployments to be owned by a specific user. When creating or editing a Project, you have a new toggle switch to enable or disable Deployment sharing:
When Deployment sharing is enabled each member can view and manage the Deployments that are part of a Project, and that is still the default model when you create a new project or for any projects created prior to the update.
With Deployment sharing disabled members with the Administrator role can view and manage all Deployments in the Project. Users with the Member role can only view and manage Deployments that they own.
Example Deployment Sharing Permissions
Let’s take a look at an example – I’ve created three projects, and I have three users who have been assigned roles within these projects:
- Project a, with Deployment sharing enabled
- Brian is Administrator
- Shawna and Scott are Members
- Project b, with Deployment sharing disabled
- Brian is Administrator
- Shawna and Scott are Members
- Project c, with Deployment sharing disabled
- Brian, Shawna and Scott are Members
Each user has deployed one application in each Project, so the Project, User Role and Deployment layout is shown here:
This translates to the following ownership and access rights:
Configuring vRA Cloud
What does this look like when we configure it in vRA Cloud? You can see from the screenshots below that each Project is configured with the Deployment sharing setting and User Roles as described above:
Once the projects are created and configured, I can deploy each users’ applications.
If I log in as Brian, we can see all the Deployments in Project a, because Deployment sharing is on, all the Deployments in Project b, because Brian is an Administrator, and only Brian’s Deployment in Project c, because he is the owner (7 Deployments in total):
So far, so good! If I log out of Brian’s account and log in as Shawna, I can see all the Deployments in Project a, but only Shawna’s Deployments in Project b and Project c:
And finally, if I log in as Scott I can once again see all the Deployments in Project a, but only Scott’s Deployments in Project b and Project c:
But what happens if I revoke Scott’s membership of Project b? Well, Scott can no longer see his Deployment in Project b (note that membership is cached for ~30m, so he’ll need to log out and in to refresh it, and the same goes for the API):
It’s also worth noting that the filters are also updated with the context – so for example Scott can now only filter based on Project a and Project c, but this is true for any of the filter types (Cloud Accounts, Cloud Types, Deployment Status, Projects etc.)
In Summary
As you can see, enabling or disabling shared deployment ownership provides quite a lot of possible combinations for controlling access to Deployments – to recap:
With shared deployment on:
- Everyone can see all the Deployments in the Project
With shared deployment off:
- Project Administrator roles can see all Deployments in the Project
- Project Member roles can see all Deployments they own in the Project
