Duo Agent Platform requires the host to be able to resolve public hostnames in proxy environment

Summary

Duo Agent Platform requires the host machine to be able to resolve public hostnames when in a proxy environment. This can cause instances with a proxy configured, but no native method of resolving hostnames to lost Duo functionality.

This mainly impacts:

  • Duo Health Check (returns blank results)
  • GitLab Credits dashboard (fails to load entirely)
  • Various DAP functionality, including fetching available models and starting workflows with the Cloud AI Gateway

GitLab team members can view the initial internal RFH.

Steps to reproduce

  1. Configure a VM with a proxy (such as Squid) and purposefully malform your /etc/resolv.conf.
  2. Install GitLab
  3. Add a licence with Duo Core add-on
  4. Try to run the health check, view GitLab Credits page or use DAP functionality.

Example Project

N/A

What is the current bug behavior?

When a host has a proxy configured for GitLab, but is unable to resolve DNS/hostnames with /etc/resolv.conf (i.e. only able to resolve through the proxy), Duo functionality does not work.

The Duo Health Check for instance fails with the below, when trying to use getaddress to determine whether to use https_proxy or no_proxy when

{
  "exception.class": "Rack::Timeout::RequestTimeoutException",
  "exception.message": "Request ran for longer than 60000ms",
  "exception.backtrace": [
    "uri (1.1.1) lib/uri/generic.rb:1557:in `getaddress'",
    "uri (1.1.1) lib/uri/generic.rb:1557:in `find_proxy'",
    "net-http (0.6.0) lib/net/http.rb:1874:in `proxy_uri'",
    "net-http (0.6.0) lib/net/http.rb:1859:in `proxy?'",
    "gems/gitlab-http/lib/net_http/connect_patch.rb:41:in `connect'",
    "gems/gitlab-http/lib/gitlab/http_v2/net_http_adapter.rb:24:in `connect'"
  ]
}

What is the expected correct behavior?

This should be documented as a prerequisite for using Duo on a self-managed instance, or the logic improved to work around these scenarios.

Relevant logs and/or screenshots

{
  "exception.class": "Rack::Timeout::RequestTimeoutException",
  "exception.message": "Request ran for longer than 60000ms",
  "exception.backtrace": [
    "uri (1.1.1) lib/uri/generic.rb:1557:in `getaddress'",
    "uri (1.1.1) lib/uri/generic.rb:1557:in `find_proxy'",
    "net-http (0.6.0) lib/net/http.rb:1874:in `proxy_uri'",
    "net-http (0.6.0) lib/net/http.rb:1859:in `proxy?'",
    "gems/gitlab-http/lib/net_http/connect_patch.rb:41:in `connect'",
    "gems/gitlab-http/lib/gitlab/http_v2/net_http_adapter.rb:24:in `connect'"
  ]
}

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 
(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖