Epic Goal

Since ACM 2.9, a cluster can be registered to an ACM hub through a forward proxy. It helps customers to manage their clusters in the isolated network environments with ACM. Whereas there are still some user scenarios where ACM can not work well, for example, the ACM hub is behind an intermediate component, like a VIP, a load balancer, a reverse proxy or an API gateway.

The goal of this epic is to support the cases where a customer has a VIP/load balancer or a reserve proxy between the spokes and the hub. Not only communication to the hub's apiserver have to work, but also every managed cluster component that talk to another one in the hub has to keep working (i.e. metrics collector in MCs writing to observatorium in the Hub).

This should not be confused with work to support HTTPS proxy with custom CA bundle, which is already supported in ACM 2.10. 

Why is this important?

Every layer of the product needs to support this, this Epic is to make sure Observability supports it

Scenarios

Support use cases 1 and 2 from https://docs.google.com/document/d/1QKK-sQ_KNuYdFily2G_cIuoyVdy6hUODmuRuA6vBArE/edit#heading=h.2395n33tp3ev, which here are separated into:

• kube apiserver communication
• hub-hosted routes (i.e. observatorium api)

Acceptance Criteria

Spokes can communicate with hub's API server through a vip/load balancer or reverse proxy using the configuration described in ACM-9663.

Spokes can communicate with observability components hosted in the hub, like the Observatorium API.

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. The QA team has worked on a test environment for this when the feature was added to the MCE (see https://issues.redhat.com/browse/ACM-8810 and https://docs.google.com/document/d/1HiK_gDr_jT0eBZjD4kTnrDPL72qalbPuSFo5cn4FMvk/edit#heading=h.ngrps53rxvoi). Ask them for help to get an environment to test this. 

Open questions:

1. It seems like the hub's kubeconfig that is installed in managed clusters are built and delivered by the MCE. This means that potentially we have nothing to do when talking to the api server.
2. How can we support make it work for access to other hub cluster's routes (i.e. Observatorium API)?

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub
  Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub
  Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Doc issue opened with a completed template. Separate doc issue
  opened for any deprecation, removal, or any current known
  issue/troubleshooting removal from the doc, if applicable.