adding proxy support

[tejasd1990]

• fix approaches
  • pass the proxy settings as input variables to the extension. This is the simplest approach. The disadvantages are that there is a repetition of settings(customers might have set them already on the machine as environment variables), and it requires making changes in the UX. Since the issues we have had so far is for the byos scenarions, and the byos scenario is more involved with ux rather than the deploymentgroup scenario, ux changes are more important for byos scenario.
  • the extension reading the proxy settings from environment. The main problem with this approach is that the proxy might be authenticated, in which case we are asking users to store the password in plain text as environment variable. The pipelines agent, which the extension configures, itself accepts the password as a command line argument and stores it in a secure manner. Another issue is that we are asking all the users to set environment variables on their machines. There are different ways to do it for windows and linux. On Windows, setting machine level environment variables will work, since the Azure agent(the parent process of the extension) will read those and pass them to the extension. But on linux, the Azure agent works as a systemd service, which clears out the environment of the process, so so we need to set the environment variables in either a specific systemd service's config file, or a generic config file for all systemd services. This is not a general solution like for windows, where setting the env. variables across the machine will work.
  • start with environment variables, only for non-authenticated proxy, and then later add inputs which will include proxy credentials as well. This also seems fair, since the existing customers who have asked for proxy support are using non-authenticated proxy.
• implementation:
  • for any http call the extension makes, we need to redirect it to the proxy server. The proxy may be authenticated, which is identified by whether the username or password is provided by the user.
  • the places where the extension makes http calls are:
  • making a number of direct http calls like during validations, adding tags etc
  • downloading files: for deploymentgroup scenario, we download the extension, and for byos, we download the extension and the enable script.
  • in both the scenarios, we install the agent. In deploymentgroup scenario, installation is part of the extension code, whereas for byos scenario, installation is part of the script, so need to make changes there as well separately.
  • on linux, for both scenarios, we install dependencies via commands, which again require http calls
• repro setup
  • Proxy server: I created a Windows vm with fiddler installed. The fiddler acts as proxy. The machine needs to accept incoming connections on the port which fiddler listens to.
  • User machine: Another Azure vm behind a firewall, and outbound traffic to only the proxy server is allowed.