Description of problem: It's possible to access /v2/_catalog even if container support is disabled. It's perceived as a security risk by a customer. Version-Release number of selected component (if applicable): 4.4.0 How reproducible: # curl https://localhost/v2/_catalog -k {"repositories":[]} # cat /etc/rhui/rhui-tools.conf | grep container container_client_auth: true [container] container_support_enabled: False # rpm -qa | grep rhui rui-tools-libs-4.4.0.5-1.el8ui.noarch rhui-tools-4.4.0.5-1.el8ui.noarch rhui-installer-4.4.0.5-1.el8ui.noarch I believe the endpoint shouldn't be available.
In general, RHUA:443 should be configured to be accessible only by the RHUA node itself, and from CDS nodes if RHUI has been installed with "--container-support-enabled True" or "--fetch-missing-symlinks True". No external users/attackers should be able to access the catalog directly on the RHUA. This access should be limited on the firewall / security group level. Because, if RHUA:443 is accessible from the outside, you have a much bigger problem -- the Pulp API is then public, which includes the admin web UI and freely browsable repositories. Only the load balancer should be public facing, and when container support is disabled, https://LB/v2/_catalog will return HTTP 404. I don't think it's a risk if the (empty) catalog is available from the RHUA's localhost interface, but if you have specific concerns about this, please let me know.