Bug 1923793

Summary:	[RFE] Add feature in satellite/capsule to reduce a large number of network ports
Product:	Red Hat Satellite	Reporter:	Ganesh Payelkar <gpayelka>
Component:	Documentation	Assignee:	Marie Hornickova <mdolezel>
Documentation sub component:	default	QA Contact:
Status:	CLOSED CURRENTRELEASE	Docs Contact:
Severity:	medium
Priority:	unspecified	CC:	ahumbe, bangelic, ehelms, ifowler, mmccune, mmj
Version:	6.9.0
Target Milestone:	Unspecified
Target Release:	Unused
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-08-07 19:47:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ganesh Payelkar 2021-02-01 22:37:48 UTC

Description of problem:

[RFE] Add feature in satellite/capsule to reduce a large number of network ports 

Version-Release number of selected component (if applicable):
Satellite 6.9

How reproducible:
Always 

Steps to Reproduce:
1. Install new satellite/External capsule 
2. To connect satellite <--> capsule <--> client we have to open a number of ports
3. It has to be open at proxy/firewall/Internal iptables according to the requirement. 

Actual results:

We have multiple ports that need to be open at each end.

- Section: "Enabling Connections from a Client to Satellite Server"
- Section:  "Enabling Connections from Capsule Server to Satellite Server"
- Section:  "Enabling Connections from Satellite Server and Clients to Capsule Server"


Each port has a different usage, So accordingly we have to send a request to the network team for opening ports. 

1.6. Ports and Firewalls Requirements
https://access.redhat.com/documentation/en-us/red_hat_satellite/6.8/html/installing_satellite_server_from_a_connected_network/index

         
1.6. Ports and Firewalls Requirements
https://access.redhat.com/documentation/en-us/red_hat_satellite/6.8/html-single/installing_satellite_server_from_a_connected_network/index#satellite-ports-and-firewalls-requirements_satellite


         The ports which satellite requires to be opened is different because the purpose of communication differs. Red Hat satellite needs to communicate to Capsule server for its content management etc, but capsule needs to communicate to Satellite Server for various purposes like sending reports regarding a host to Satellite Server, etc.




Expected results:

So, instead of opening multiple ports at each end, possible for us to have a few or a single port, which will be used to communicate from each end? 


Additional info:

This will be a product enhancement, because the large number of parts required, as well as the communication requirement in both directions, is
a) not firewall-friendly in highly segmented networks
b) a large number of required ports and the protocols required to operate Satellite 6 is perceived as a security risk.

This request is for a product enhancement to reduce the required ports for core functionality to https (tcp/443) in one direction only.

Comment 2 Marek Hulan 2021-10-13 15:46:53 UTC

There is a work in progress on the documentation of all required ports and mapping it to features that customer may or may not be using. That should lead to easier decisions on what ports customer needs to enable. It's impossible to reduce the number of ports as each Satellite service needs it's own and dedicated port. However with better describing what functionality requires what port will help customer to reduce the firewall exceptions to minimum.

Moving this bug to the documentation for now. Ian, could you please link your work here?

Comment 3 Mark Meierjohann 2021-10-13 23:21:52 UTC

If Satellite 6 continues to require the large number of ports opened in both directions, it will be less usable in modern, highly firewalled and security managed environments.

This request is for making communication more friendly for modern environments, using less ports, preferably just one, and single direction communication.

I strongly suggest to reconsider moving this request to documentation only. Documenting this does not make the product any better.