Your best bet is try and fix this issue from a vSphere standpoint and not try and tackle it from a vRA standpoint. You'd best do that by separating roles/permissions so no one except for maybe one account can convert those templates to VMs. If they can't convert a template to a VM, it can't be powered on and thus it can't be altered.
You are right, why to complicate things unnecessary.
1 person found this helpful
As daphnissov mention, this is more related to the vSphere and not vRA.
We have the same requirements from IT Security. And I guess if you talk to them, this is all about tracking. They need to be able to trace what happends to an template (not really deny changes).
You can add "deny" to the folder (or template directly) where they are stored in vSphere it will take presence over any "allow" rules. But you need to keep it up to date every time a new group/person is added. This is easly missed and anyone with access can remove the deny anyway.
As a suggestion, this is our solution:
We use Log Insight and vROps to track any changes to templates, so basically there is only one user who should update our templates (a vRO scheduled task who auto updates the templates). If anyone else writes/updates/convert the templates there is an "alarm" triggered in vROps.
My guess is, if you talk to the security guys, they should be more happy with a solution like this.