Bug 1415273

Summary:	[RFE]: Enable HE VM deployment to different subnet from the hypervisor
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Pawan kumar Vilayatkar <pvilayat>
Component:	RFEs	Assignee:	Martin Tessun <mtessun>
Status:	CLOSED WONTFIX	QA Contact:	Raz Tamir <ratamir>
Severity:	medium	Docs Contact:
Priority:	low
Version:	unspecified	CC:	danken, lsurette, michal.skrivanek, mtessun, pvilayat, rbalakri, srevivo, ykaul, ylavi
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-06-06 12:48:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Network	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Pawan kumar Vilayatkar 2017-01-20 17:49:26 UTC

- What is the nature and description of the request?
Enable Self Hosted Engine deployment to different subnet from the hypervisor

- Why do you need this? (List the business requirements here)
From a network security perspective we split hypervisors from management software since they have different needs for inbound/outbound communication.
Also we could have a scenario where we have hypervisors on two different network zones that are not allowed to communicate with eachother, but are allowed to communicate with a common management zone.
One other issue with the deployment is that it requires a pingable gateway, and that is usually not available in a firewalled environment.



- How would you like to achieve this? (List the functional requirements here)
Enable deployment of self hosted engine on any subnet/vlan available to the hypervisor where it will be running.
Remove check for pingable gateway.


- Do you have any specific time-line dependencies?
No


- List any affected packages or components. 
Self hosted engine



- Would you be able to assist in testing this functionality if implemented?
Yes


- For each functional requirement listed in the previous question, can test to confirm the requirement is successfully implemented
Yes

Comment 1 Martin Tessun 2017-02-14 08:48:30 UTC

Hi Pawan,

(In reply to Pawan kumar Vilayatkar from comment #0)
> - What is the nature and description of the request?
> Enable Self Hosted Engine deployment to different subnet from the hypervisor
> 
> - Why do you need this? (List the business requirements here)
> From a network security perspective we split hypervisors from management
> software since they have different needs for inbound/outbound communication.
> Also we could have a scenario where we have hypervisors on two different
> network zones that are not allowed to communicate with eachother, but are
> allowed to communicate with a common management zone.
> One other issue with the deployment is that it requires a pingable gateway,
> and that is usually not available in a firewalled environment.

I don't get the security aspect here. The HE needs to communicate with the Hypervisors on the management LAN. So it needs to be in the same network as the Hypervisors.

The pingable gateway itself is simply a host that is expected to be available all the time and if it is not, then the network is broken.
So even in a firewalled environment, you have at least the firewall interface that is pingable (or at least could be configured this way).

So the only piece remaining is the RHV-M Web-UI (https/port 443) and (if used) the central authentication (AD or LDAP).

Both could be configured via a second interface that is added to hosted engine after install. With the appropriate firewall rules you could then separate this traffic.
From a security point of view, I believe this is more "dangerous" than having a firewall controlled access to https port (incoming) and central authentication if needed (outgoing).

As such I do not understand the reasoning behind moving the management to a different zone.

Could you please elaborate a bit more on why this is needed?
Thanks!
Martin

Comment 5 Michal Skrivanek 2017-03-10 14:10:29 UTC

moving to HE deployment

Comment 8 Franta Kust 2019-05-16 13:07:04 UTC

BZ<2>Jira Resync