Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-2772

Support repo access via SSH with a proxy

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Normal Normal
    • 1.13.0
    • None
    • ArgoCD, Operator
    • False
    • None
    • False
    • 0% To Do, 0% In Progress, 100% Done

      Feature: Support repo access via SSH with a Socks5 proxy

      Add support for Socks5 addresses (IP:port) in the `proxy` field of the ArgoCD repository Secret when the repository type is Git via SSH

      Goals

      Argo CD already supports repo access via a proxy, but only using HTTP/S, see the upstream documentation here.

      Some organisations have restrictions against accessing any resources via HTTP/S and are currently unable to access their git repositories via their proxy in Argo CD. This effectively makes Argo CD unusable for these organisations.

      Once we add support for SSH over Socks5 in addition to HTTP/S, these customers will be able to access their repos and meet their organisation’s requirements.

      Requirements

       

      Requirements Notes IS MVP
      Users of Argo CD can access their git repos through a Socks 5 proxy using SSH    
      OpenShift GitOps users have access to this improvement Support is brought downstream  
      HTTP/S proxy access is still available, SSH is additional not a replacement    

       

      Use Cases

      Case #03450166 

       

      We need to configure ssh access to a GIT repo from ArgoCD using the Openshift Gitops Operator through a socks5 proxy.
      We did a POC using ArgoCD (Openshift Gitops Operator) connecting to a GIT repo directly and now we need to use the git that is in the organization.
      This GIT is behind a proxy and we must use ssh using socks5 proxy(http/https connections to GIT are forbidden).
      

       

      Out of scope

      Dependencies

      Background, and strategic fit

      Customer is blocked from moving past the POC phase of their implementation without this feature. It’s not currently impacting development or production etc. but without this being resolved they are effectively prevented from using the OpenShift GitOps operator in their organisation.

      As we gain traction in larger organisations this type of organisation-level security requirement will become more prevalent. Fixing this in a timely manner is important to our team so that we aren’t blocking adoption of our operator. Our operator’s adoption is a key metric that we track to assess success.

      Assumptions

      Customer Considerations

      See the related customer case for further information on the customer environment.

      Documentation Considerations

      Upstream documentation will be required for this feature.

      What does success look like?

      • The feature is accepted upstream
      • We are able to resolve the specific customer’s issue listed above
      • Customers are able to find the documentation needed to configure repo access via a proxy using ssh
      • We don’t receive support requests asking how to use this feature or asking if it exists

      QE Contact

      Impact

      Related Architecture/Technical Documents

      Implementation information from Jann via Slack thread:

       

      The issue is that Argo CD uses two different means of accessing Git: One is via go-git, which is a pure Go implementation of Git that uses go's x/crypto/ssh library for SSH transport, and the other one is via fork/exec of the Git binary, which in turn uses OpenSSH binaries for SSH transport. I believe that while x/crypto/ssh can read a .ssh/config user configuration, it will not support all of its settings (such as Proxycommand in this case). Possibly, we need to make this a first class feature in Argo CD (e.g. to specify the proxy in the repository configuration, as is possible today with repositories connected via HTTPS)
      

      Done Checklist

      • Acceptance criteria are met
      • Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
      • User Journey automation is delivered
      • Support and SRE teams are provided with enough skills to support the feature in production environment

            rh-ee-anjoseph Anand Francis Joseph
            halawren@redhat.com Harriet Lawrence
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: