My team is working to move to using the Software Component capabilities in VRA 7.3. Currently everything we do for provisioning is done using stub workflows we developed in VRO when we were on VRA 6.2. I need to get a better understanding of how the communication works, because our Information Security is concerned that we have tenant VM's initiating communication to our cloud management platform. We obviously need to prevent bad actors from having the ability to have any type of communication to this platform.
From what I understand, this is how Software Components work in general. I'd appreciate it if anyone can correct me on how this work.
I need to know how VRA prevents just any server from providing the unique ID (which I believe is the gugent ID that is readily available in files in the gugent folder on each VM) so that VRA then starts working with that VM.
Any help would be greatly appreciated.
You have it essentially correct with one minor qualification.
- VRA assigns a unique ID for the gugent
The gugent (guest agent) is a separate agent. Software components are controlled by a separate agent which is a perpetual service/daemon referred to as the software bootstrap agent. The two are separate functionality.
I need to know how VRA prevents just any server from providing the unique ID (which I believe is the gugent ID that is readily available in files in the gugent folder on each VM) so that VRA then starts working with that VM.
There are a couple mechanisms. The first are the SSL certificates that must be installed within and accepted on the template, and those consist of the cert presented by the front-end as well as the Manager service. The second is the ID which is a run-time artifact. The ID ties the agent back to the Manager service and submits work items to it. Any "bad actors" can't really affect this system because they either don't have the SSL cert or don't possess (and cannot snoop) the ID. Plus, these components are only pushed at various lifecycle stages. It's not that an agent--even if compromised--can simply "request" a software component and have it brought down upon demand.
You have it essentially correct with one minor qualification.
- VRA assigns a unique ID for the gugent
The gugent (guest agent) is a separate agent. Software components are controlled by a separate agent which is a perpetual service/daemon referred to as the software bootstrap agent. The two are separate functionality.
I need to know how VRA prevents just any server from providing the unique ID (which I believe is the gugent ID that is readily available in files in the gugent folder on each VM) so that VRA then starts working with that VM.
There are a couple mechanisms. The first are the SSL certificates that must be installed within and accepted on the template, and those consist of the cert presented by the front-end as well as the Manager service. The second is the ID which is a run-time artifact. The ID ties the agent back to the Manager service and submits work items to it. Any "bad actors" can't really affect this system because they either don't have the SSL cert or don't possess (and cannot snoop) the ID. Plus, these components are only pushed at various lifecycle stages. It's not that an agent--even if compromised--can simply "request" a software component and have it brought down upon demand.
Also, not that you asked, but it's worth pointing out that software components only function if you have a vRA Enterprise license. An Advanced license will not work.