Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-37052

LDAP communication going through HTTP(S) proxy

XMLWordPrintable

    • Moderate
    • None
    • Hypershift Sprint 257, Hypershift Sprint 258, Hypershift Sprint 259
    • 3
    • False
    • Hide

      None

      Show
      None
    • Hide
      * Previously, proxying for Operators that run in the control plane of a hosted cluster was performed through proxy settings on the Konnectivity agent pod that runs in the data plane. It was not possible to distinguish if proxying was needed based on application protocol.

      For parity with OpenShift Container Platform, IDP communication via HTTPS or HTTP should be proxied, but LDAP communication should not be proxied. This type of proxying also ignores `NO_PROXY` entries that rely on host names because by the time traffic reaches the Konnectivity agent, only the destination IP address is available.

      With this release, in hosted clusters, proxy is invoked in the control plane via `konnectivity-https-proxy` and `konnectivity-socks5-proxy`, and proxying traffic is stopped from the Konnectivity agent. As a result, traffic that is destined for LDAP servers is no longer proxied. Other HTTPS or HTTPS traffic is proxied correctly. The `NO_PROXY` setting is honored when you specify hostnames. (link:https://issues.redhat.com/browse/OCPBUGS-37052[*OCPBUGS-37052*])
      Show
      * Previously, proxying for Operators that run in the control plane of a hosted cluster was performed through proxy settings on the Konnectivity agent pod that runs in the data plane. It was not possible to distinguish if proxying was needed based on application protocol. For parity with OpenShift Container Platform, IDP communication via HTTPS or HTTP should be proxied, but LDAP communication should not be proxied. This type of proxying also ignores `NO_PROXY` entries that rely on host names because by the time traffic reaches the Konnectivity agent, only the destination IP address is available. With this release, in hosted clusters, proxy is invoked in the control plane via `konnectivity-https-proxy` and `konnectivity-socks5-proxy`, and proxying traffic is stopped from the Konnectivity agent. As a result, traffic that is destined for LDAP servers is no longer proxied. Other HTTPS or HTTPS traffic is proxied correctly. The `NO_PROXY` setting is honored when you specify hostnames. (link: https://issues.redhat.com/browse/OCPBUGS-37052 [* OCPBUGS-37052 *])
    • Bug Fix
    • Done

      Description of problem:

      This is a followup of https://issues.redhat.com/browse/OCPBUGS-34996, in which comments led us to better understand the issue customers are facing.

LDAP IDP traffic from the oauth pod seems to be going through the configured HTTP(S) proxy, while it should not due to it being a different protocol. This results in customers adding the ldap endpoint to their no-proxy config to circumvent the issue.

      Version-Release number of selected component (if applicable):

      4.15.11

      How reproducible:

      Steps to Reproduce:

       (From the customer)   
    1. Configure LDAP IDP
    2. Configure Proxy
    3. LDAP IDP communication from the control plane oauth pod goes through proxy instead of going to the ldap endpoint directly

      Actual results:

          LDAP IDP communication from the control plane oauth pod goes through proxy

      Expected results:

          LDAP IDP communication from the control plane oauth pod should go to the ldap endpoint directly using the ldap protocol, it should not go through the proxy settings

      Additional info:

      For more information, see linked tickets.

              cewong@redhat.com Cesar Wong
              cbusse.openshift Claudio Busse
              Jie Zhao Jie Zhao
              Laura Hinson Laura Hinson
              Votes:
              0 Vote for this issue
              Watchers:
              13 Start watching this issue

                Created:
                Updated:
                Resolved: