Review firewall requirements #4210
Conversation
github-actions
bot
added
Needs tech review
aneta-petrova
force-pushed
the
review-port-requirements
branch
from
eb83efb to
d1edc57
Compare
aneta-petrova
force-pushed
the
review-port-requirements
branch
6 times, most recently
from
b74d86b to
0690c02
Compare
|
Hi @ekohl, this is my idea for how to split and organize the docs about ports between Planning and Installation. Can you please take a look? Does this go in the direction that you had in mind? |
aneta-petrova
force-pushed
the
review-port-requirements
branch
from
41c3420 to
9d189e0
Compare
guides/common/assembly_preparing-environment-for-capsule-installation.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/ref_smart-proxy-port-and-firewall-requirements.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/ref_project-server-port-and-firewall-requirements.adoc
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
For this chapter we run into the naming problem: Capsule in downstream is IMHO something quite different than a Smart Proxy.
My interpretation:
- Smart Proxy: the generic concept that Foreman connects to
- Foreman Proxy: the Ruby implementation of Smart Proxy
- Capsule: The downstream naming for a server that has a few services: Foreman Proxy, Pulp, Apache (for the RHSM registration API). Upstream we sometimes refer to this as Content Proxies: a Proxy with a set of content features.
Now looking ahead we're going to make this a bigger problem. The Insights on Premise is also recognized as a Smart Proxy. Then with pulp_smart_proxy the Pulp server can identify as a Smart Proxy.
In other words: I think soon we need to have the discussion within Red Hat: where do we want to go with this. Do we stop branding Smart Proxy as Capsule?
There was a problem hiding this comment.
I don't think this is actionable right now but it's interesting information so I'll keep this thread open for awareness.
aneta-petrova
force-pushed
the
review-port-requirements
branch
from
1b3c6c8 to
6772d24
Compare
|
A tech review should focus on these two things:
|
aneta-petrova
force-pushed
the
review-port-requirements
branch
from
26efb19 to
84004cc
Compare
There isn't but I'm trying to get an idea of the required lists of services first. Once I have that, I'll figure out how to include them more efficiently. |
@evgeni After agreeing to resolve the question of which ports need to be opened later (tracked in #4247), do you think the procedure as it is now is okay?
@ekohl @evgeni Have either of you had the chance to look at the changes in the Planning guide? |
maximiliankolb
added
the
Waiting on contributor
aneta-petrova
force-pushed
the
review-port-requirements
branch
from
68e34c0 to
f7c2828
Compare
There was a problem hiding this comment.
All those comments about which ports don't need to be open by default are great, thanks a lot, Evgeni and Ewoud! I created #4247 a few days ago so I added them there.
Co-authored-by: Ewoud Kohl van Wijngaarden <[email protected]>
Thanks! @ekohl @maximiliankolb Do you have any further comments? |
| [NOTE] | ||
| ==== | ||
| Some outgoing traffic returns to {Project} to enable internal communication and security operations. | ||
| ==== | ||
|
|
There was a problem hiding this comment.
I don't quite understand this & it seems rather confusing. "some" sounds bad and unspecific from a security perspective. Does this admonition add any value to users? I am leaning towards no.
| [NOTE] | |
| ==== | |
| Some outgoing traffic returns to {Project} to enable internal communication and security operations. | |
| ==== |
Was this part of the docs before? If so, feel free to ignore my comment/move this to an GH issue.
There was a problem hiding this comment.
I'd like to resolve this here so that we're sure the reviewed requirements are okay. @evgeni can you shed some light on this? Can we perhaps specify the note? Or is it safe to drop it?
There was a problem hiding this comment.
Well, it was added in #2451 and is frankly a tad confusing.
So strap on your best glasses, we're using a Tardis!
The bug that #2451 was trying to fix (https://bugzilla.redhat.com/show_bug.cgi?id=2233266) was reported against Satellite 6.13, and we look at https://docs.redhat.com/en/documentation/red_hat_satellite/6.13/html/installing_satellite_server_in_a_connected_network_environment/preparing_your_environment_for_installation_satellite#Ports_and_Firewalls_Requirements_satellite we see the following entries with "Satellite" as the destination:
| Destination Port | Protocol | Service | Destination | Required For | Description |
|---|---|---|---|---|---|
| 443 | TCP | HTTPS | Satellite | Capsule | Capsule, Configuration management, Template retrieval, OpenSCAP, Remote Execution result upload |
| 5646 | TCP | AMQP | Satellite Server | Katello agent | Forward message to Qpid dispatch router on Capsule (optional) |
| 5671 | Satellite Server | Remote install for Katello agent | Send install command to client | ||
| 5671 | Satellite Server | Remote install for Katello agent | Forward message to dispatch router on Satellite |
(Yes, protocol and service are missing for the last two lines, yes "Satellite" vs "Satellite Server" is inconsistent, have a 🍷 for me please)
Now, it is true that the way Katello agent communication was set up, the Germans would call "from behind, through the chest, into the eye" (Sorry Anet, if you don't have a visual picture of the pain, I either owe you one, or you can count yourself lucky, or both).
Luckily for us, today, stepped out of the Tardis again: Katello agent is a sin of the past and we don't have to care about it anymore and can solely focus on the one remaining entry in todays docs:
| Destination Port | Protocol | Service | Destination | Required For | Description |
|---|---|---|---|---|---|
| 443 | TCP | HTTPS | Satellite | Capsule | Capsule, Configuration management, Template retrieval, OpenSCAP, Remote Execution result upload |
And the great thing? It's nonsense! I mean, yeah, the external Capsule needs to be able to talk to the Satellite on port 443 (and others!) but that should be covered by "{Project} incoming traffic" and "{SmartProxy} outgoing traffic" and never be part of "{Project} outgoing traffic"
So, my verdict is:
- drop that note
- drop line 65-73 of
guides/common/modules/ref_project-server-port-and-firewall-requirements.adoc(| 443 | TCP | HTTPS | {Project} | {SmartProxy} | {SmartProxy} …)
There was a problem hiding this comment.
That was quite the suspenseful read. I wish more comments were like this.
Also, it really helps that you summarized it at the end to tell me what it is that I'm supposed to do 😆 So I removed both the note and the row.
guides/common/modules/ref_project-server-port-and-firewall-requirements.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/ref_smart-proxy-port-and-firewall-requirements.adoc
Outdated
Show resolved
Hide resolved
pr-processor
bot
added
the
Waiting on contributor
Co-authored-by: Maximilian Kolb <[email protected]>
pr-processor
bot
added
Needs re-review
and removed
Waiting on contributor
maximiliankolb
added
style review done
maximiliankolb
added
tech review done
* Move port & firewall to Planning and review it * Review port procedure * Update installing postgresql to work without firewall snippets * Drop firewall-cmd snippet from provisioning * Merge modules on opening ports * Drop integrated/external proxy definitions Integrated/external proxy was reported as flawed concept that we should get rid of. * Drop obsolete information on outgoing traffic --------- Co-authored-by: Maximilian Kolb <[email protected]> Co-authored-by: Ewoud Kohl van Wijngaarden <[email protected]> (cherry picked from commit e561a50)
What changes are you introducing?
Why are you introducing these changes? (Explanation, links to references, issues, etc.)
This is part of preparing the installation prerequisites for the new installation guide in #4087
Anything else to add? (Considerations, potential downsides, alternative solutions you have explored, etc.)
N/A
Contributor checklists
Please cherry-pick my commits into:
Review checklists
Tech review (performed by an Engineer who did not author the PR; can be skipped if tech review is unnecessary):
Style review (by a Technical Writer who did not author the PR):