Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-56485

RFE: Add Support for VPN Proxy for Starting Agents

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Our network configuration requires that our Master, in one DMZ, start an agent in another DMZ that are separated by firewalls, proxies, and a VPN bridge with separate credentials from the agent machine.

      This is a request to add the following to SSH Slaves:

      1. Host IP/name of the VPN proxy.
      2. A field to specify the command to launch a VPN proxy. Sample: `openconnect --protocol=gp --server-key=... --user=something --key-password=something`
      3. A credential specification to be used for the VPN proxy.
      4. Launching the VPN proxy command.
      5. Continue with SSH startup of the agent JVM but from an SSH session initiated on the VPN proxy instead of initiated from the master.

      There are actually three distinct sets of credentials involved here:

      • Controller to VPN proxy SSH keys
      • VPN proxy to VPN server keys (whichever they use, probably user/password)
      • Controller to Agent SSH keys once the VPN connection is established.

      The original thought was to use or even take over the now defunked openconnect plugin, but that seems to have disappeared. There are many different possible VPN solutions, with openconnect being one of them. This enhancement would remove the need to establish a static VPN connection available to all users and Jenkins instances on the Controller.

        Attachments

          Issue Links

            Activity

            Hide
            rsbeckerca Randall Becker added a comment -

            We have experienced the same need. Our Controller is running in a Docker container and we very much like it that way from a manageability and security standpoint. Our Agent is currently running on a machine accessible from the Docker image over SSH. However, because of security policies being implemented, the server is being moved to a different network segment behind a VPN. We have a few options:

            1. Starting the VPN in the underlying Linux machine and allow the Docker container to use it whenever needs it. This has the very undesirable effect of costing a lot of money because the VPN is metered via connection time.
            2. Manually starting and stopping the VPN connection. This will prevent the Agent from connecting automatically.
            3. Putting the VPN client in the Docker image, which is not recommended by Docker. This still causes issues relating to the agent, which we need to be on-demand, so there's still manual step involved in the VPN client by mucking about in the Docker image.
            4. There are probably more, but none of these are desirable.

            Ideally, our Agent configuration would establish the VPN connection locally and then we can connect over SSH. This could be contained within the Agent setup itself.

            Show
            rsbeckerca Randall Becker added a comment - We have experienced the same need. Our Controller is running in a Docker container and we very much like it that way from a manageability and security standpoint. Our Agent is currently running on a machine accessible from the Docker image over SSH. However, because of security policies being implemented, the server is being moved to a different network segment behind a VPN. We have a few options: Starting the VPN in the underlying Linux machine and allow the Docker container to use it whenever needs it. This has the very undesirable effect of costing a lot of money because the VPN is metered via connection time. Manually starting and stopping the VPN connection. This will prevent the Agent from connecting automatically. Putting the VPN client in the Docker image, which is not recommended by Docker. This still causes issues relating to the agent, which we need to be on-demand, so there's still manual step involved in the VPN client by mucking about in the Docker image. There are probably more, but none of these are desirable. Ideally, our Agent configuration would establish the VPN connection locally and then we can connect over SSH. This could be contained within the Agent setup itself.

              People

              Assignee:
              ifernandezcalvo Ivan Fernandez Calvo
              Reporter:
              rsbeckerca Randall Becker
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated: