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

[release-4.15] LDAP communication going through HTTP(S) proxy

XMLWordPrintable

    • 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 done through proxy settings on the Konnectivity agent pod that runs in the data plane. As a consequence, it was not possible to distinguish whether 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-38065[*OCPBUGS-38065*])
      Show
      * Previously, proxying for Operators that run in the control plane of a hosted cluster was done through proxy settings on the Konnectivity agent pod that runs in the data plane. As a consequence, it was not possible to distinguish whether 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-38065 [* OCPBUGS-38065 *])
    • Bug Fix
    • Done

      This is a clone of issue OCPBUGS-38062. The following is the description of the original issue:
      —
      This is a clone of issue OCPBUGS-37052. The following is the description of the original issue:
      —
      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.

            agarcial@redhat.com Alberto Garcia Lamela
            openshift-crt-jira-prow OpenShift Prow Bot
            Jie Zhao Jie Zhao
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: