Uploaded image for project: 'Satellite'
  1. Satellite
  2. SAT-37836

Impossible to generate registration command via REST API in isolated networks managed by external capsules

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 6.16.z, 6.17.z, 6.18.0
    • Registration
    • False
    • Proton Refinement Backlog
    • sat-proton
    • None
    • None
    • None
    • None

      Access to port 8443 and reverse-proxy through the same on a Capsule server was deprecated on Satellite 6.15, disabled on 6.16, and removed from satellite\capsule 6.17+. 

      And that is a BLOCKER for hosts in an isolated network to be able to generate the registration command.

      https://docs.redhat.com/en/documentation/red_hat_satellite/6.16/html/release_notes/deprecated-functionality#deprecated-functionality talks about the use of 
      "satellite-installer --foreman-proxy-content-reverse-proxy=true"
       

      But even that is only limited and available till Satellite \ Capsule 6.16 only. 

      It's BLOCKER for those end-users as :

      • It requires access to/api/registration_commands of satellite which none of the clients would be able to do 
      • Even to trigger the /api/registration_commands API, it needs certain inputs like, hostgroup_id or smart_proxy_id etc and to fetch them also /api/v2/hostgroups or /v2/smart_proxies endpoints are needed but they cannot be triggered as well.

       

      Someone might be able to delegate those tasks to capsule directly and capsule can fetch the data and delegate back to the hosts but it may not be suitable for every automation workflow out there with the end-users. 

       

      Given that fact that:

      • No 8443 access
      • Port 443 \ 9090 \ 8000 provides limited set of access to specific endpoints like /unattended/ and /register 
      • No hosts managed by capsules can talk to satellite directly
      • A seperate reverse proxy also cannot be used in between hosts and satellite 

       

      This is not a very good experience for any of the consumers who have a large infrastrcuture with several capsules isolated by network and firewall strictly and automated workflows.  

      It can be a fact that the support for reverse proxying through 8443 was dropped as we were concerned about security and wanted to provide full isolation of hosts e.g. they only get access to what they need ( content or provisioning stuff ) but no direct or indirect access access to Satellite\Foreman API, that perhaps is not suiting well for many of our end-users. 

      See the following JIRAs for more info:

       

      There should be a process developed for end-users to do this rather gracefully and easily. 

              Unassigned Unassigned
              rhn-support-saydas Sayan Das
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated: