VMware Cloud Community
Enter123
Enthusiast
Enthusiast
Jump to solution

vRA Deployments - ensure VM template integrity?

Hi all,

I hope you will have some tips for this.

I got a request from IT security to ensure the integrity of our VM templates we use in vRA. They want be sure no one can modify templates and install something.

Currently my templates are located on a vSAN cluster. And of course there are some people with Admin permission and some Ops people with enough permission to change templates to VMs and power them on etc.

How to ensure that those templates don't get modified by someone? I am not sure which approach to take.

Implement custom vRO workflow to do MD5sum check on VM template before each deployment?

create a VM folder and put templates there and give permission only to a vRO account so it can clone a template?

something else?

Anyone had a request like this? any tips?

Reply
0 Kudos
1 Solution

Accepted Solutions
GeiAll
Enthusiast
Enthusiast
Jump to solution

Hi Enter123.

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.

View solution in original post

3 Replies
daphnissov
Immortal
Immortal
Jump to solution

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.

Reply
0 Kudos
Enter123
Enthusiast
Enthusiast
Jump to solution

You are right, why to complicate things unnecessary.

Thank you:)

Reply
0 Kudos
GeiAll
Enthusiast
Enthusiast
Jump to solution

Hi Enter123.

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.