Bug 2159669

Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.

In short, please clarify if it needs be over encrypted connections or a port other than 80?

If it needs to be encrypted connections, then the answer is that unattended installations assume plain text connections.

If it needs to be a port other than 80, we can do that though it hasn't been verified by Red Hat and you may find places where it assumes port 80.

Longer comments inline.

(In reply to Pranjal from comment #0)
> In few environments, security is unlikely to allow traffic on port 80
> between satellite server and capsule/client in secure networks.
> 
> Any way this connection can be changed from port 80 (uncoded) to another
> port which is encrypted?

Are you asking for any traffic to pass over an encrypted connection? Because that's simply not feasible for some features.

For example, with server provisioning using Anaconda we don't have a way to bootstrap the certificate chain. It certainly was impossible in the past, though I haven't checked back recently. We have the setting `unattended_url` in Foreman which configures the URL that's used. https://anaconda-test.readthedocs.io/en/latest/boot-options.html suggest it now can, so you can try to change it to https but I think along the way there are many issues you may encounter.

> - Provisioning failed to fetch the Vmlinuz and getting timeout.

I think vmlinuz is retrieved over TFTP, which is 69/udp. It may be possible to retrieve this over HTTP using HTTPBoot, but there we don't support HTTPS either since we can't bootstrap the trust chain to verify the connection. I even recall that many implementations have been built without HTTPS support, but I never worked with it myself so I can't say for sure.

> - Customer's security team blocks any traffic on port 80 between
> 
> a) satellite->capsule

This should be fine. I don't think anything needs, or the other way around for that matter (capsule -> satellite).

> b) satellite->client

I'm assuming you mean the client -> satellite, given the client initiates the connection. As I said above: this breaks the provisioning workflow.

> c) capsule->client

Again, assuming client -> capsule. Here most of the communication to provision happens over port 8000. It's plain text HTTP because provisioning needs it. It may retrieve RPM content over HTTP too, but that's irrelevant if you can't retrieve the kickstart file over HTTP on port 8000.

> If port 80 is mandatory in satellite/capsule (such as provisioning) then we
> need this port to be configurable to other encrypted port. 

I'm assuming you mean all communication must happen over encrypted connections. Typically we don't talk about encrypted ports, but encrypted connections. Firewalls usually look at port numbers, but there's no rule you have to run something encrypted or not. It's perfectly possible to run plain text HTTP on port 443. Most people (and probably tools) will be confused if you use http://example.com:443.
 
> Expected results:
> 
> - Provisioning shall work using encrypted port other than port 80.
> - Customer should configure ports (other than port 80) in satellite server
> to communicate between satellite and capsule/clients. Currently, port 80 is
> hard coded in satellite server.

I don't mean to be pedantic, but it's not hard coded. You can use the installer options --foreman-server-port MYPORT --foreman-unattended-url http://MYHOSTNAME:MYPORT and in theory it should then use a port other than 80. It's still unencrypted, but that's why I asked to clarify: does it need to be encrypted or be a port other than 80?

In a private conversation it was pointed out that foreman_bootdisk retrieves files from the Capsule to Satellite over plain text HTTP and that's a problem. Specifically it's the ISO generator[1].

It's not obvious what the flow of the code is (since it covers 3 separate repositories), so hopefully I'm reading this right. It has code to fetch (and that appears to be able to deal with HTTPS), but then how the file URLs are determined is not trivial. It goes through the Medium provider mechanism (as implemented in Foreman) and specifically ManagedContentMediumProvider[2] (implemented in Katello) to be able to retrieve it from Pulp.

The ManagedContentMediumProvider uses the kickstart repository from the hosts' content source, which in this case is the Pulp on a Capsule. Unattended installations happen over HTTP and use the kickstart repository, so my guess is that the ISO generator ends up using HTTP too. In the case of foreman_bootdisk we're not constrained to plain text HTTP and should be able to use a secure way but the current APIs don't appear to allow this.

I'd ask someone with more knowledge of Katello, because I'm not that familiar with its internals.

Additionally, while reading up on this I think we should also start looking at retrieving kickstart over HTTPS, even if we don't verify the CA. Where needed we could work with the Anaconda team to make it happen. It would simplify our stack if we can get rid of unattended installations over HTTP. There are many considerations here and it's a non-trivial RFE. If we default to HTTPS everywhere, this issue may also not show up anymore.

[1]: https://github.com/theforeman/foreman_bootdisk/blob/master/app/services/foreman_bootdisk/iso_generator.rb#L220
[2]: https://github.com/Katello/katello/blob/master/app/services/katello/managed_content_medium_provider.rb

@bbuckingham see https://bugzilla.redhat.com/show_bug.cgi?id=2159669#c6 above from Ewoud requesting someone from the Katello team do further investigation.

I see no issue with fetching kickstart contents over HTTPS. In Pulp, the contents are served over ports 443 and 8443 (along with 80).  Take a look at /etc/httpd/conf.d/10-rhsm-pulpcore-https-443.conf and /etc/httpd/conf.d/10-rhsm-pulpcore-https-8443.conf on a Capsule for more info.

We have one example of preloading these files from a capsule here using HTTPS with certificates: https://github.com/Katello/katello/blob/master/app/services/katello/pxe_files_downloader.rb#L10

In that example, we send a GET request so that an "on demand" capsule will have the content available to avoid timeouts during provisioning.

Could foreman_bootdisk not do the same? It would just need the certificates.

---

Some notes on moving to HTTPS entirely:

For general provisioning via Katello content on a Capsule, I suppose the machines would need to get client certificates somehow.

Assuming the client machines have the certificates during provisioning time, we would need to remove the HTTP forcing that is happening here: https://github.com/Katello/katello/blob/master/app/services/katello/managed_content_medium_provider.rb#L12

The `true` at the end there is forcing HTTP.

The additional_media method there is necessary because BaseOS needs AppStream to be present in the kickstart script.

I'm not sure how we'd get the certificates sent, perhaps they could be defined in the kickstart provisioning template? Maybe that would require Anaconda support.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.