Skip to content

Unable to configure ElasticSearch if "Block all requests, except for IP addresses, IP ranges, and domain names defined in the allowlist" is enabled

Summary

If "Block all requests, except for IP addresses, IP ranges, and domain names defined in the allowlist" is enabled, Elastic Search URL is not taken into account when added to the list "Local IP addresses and domain names that hooks and integrations can access".

Steps to reproduce

  • On a self-managed GitLab instance with Premium/Ultimate license, enable Block all requests, except for IP addresses, IP ranges, and domain names defined in the allowlist via Admin > Settings > Network > Outbound requests.
  • Add your Elastic Search IP address or hostname to the list of exceptions at Local IP addresses and domain names that hooks and integrations can access and save it.
  • Go to Admin > Settings > Search > Advanced Search and try to set URL for Elastic Search.

What is the current bug behavior?

You will get the error message: Elasticsearch url only supports valid HTTP(S) URLs.

What is the expected correct behavior?

It should be possible to configure the URL for Elastic Search if it was added to the list of exceptions.

Relevant logs and/or screenshots

The following error is shown in the log /var/log/gitlab/gitlab-rails/exceptions_json.log:

{
  "severity": "ERROR",
  "time": "2025-06-24T11:42:07.133Z",
  "meta.feature_category": "observability",
  "correlation_id": "01a4443cb3dd7745915a778f1ad200ef",
  "meta.caller_id": "Observability::AlertQueryWorker",
  "exception.class": "Gitlab::HTTP_V2::BlockedUrlError",
  "exception.message": "URL is blocked: Requests to hosts and IP addresses not on the Allow List are denied",
  "exception.backtrace": [
    "gems/gitlab-http/lib/gitlab/http_v2/new_connection_adapter.rb:65:in `rescue in validate_url_with_proxy!'",
    "gems/gitlab-http/lib/gitlab/http_v2/new_connection_adapter.rb:62:in `validate_url_with_proxy!'",
    "gems/gitlab-http/lib/gitlab/http_v2/new_connection_adapter.rb:39:in `connection'",
    "httparty (0.23.1) lib/httparty/connection_adapter.rb:80:in `call'",
    "httparty (0.23.1) lib/httparty/request.rb:201:in `http'",
    "httparty (0.23.1) lib/httparty/request.rb:154:in `perform'",
    "httparty (0.23.1) lib/httparty.rb:621:in `perform_request'",
    "gems/gitlab-http/lib/gitlab/http_v2/client.rb:103:in `sync_perform_request'",
    "gems/gitlab-http/lib/gitlab/http_v2/client.rb:68:in `perform_request'",
    "httparty (0.23.1) lib/httparty.rb:531:in `get'",
    "gems/gitlab-http/lib/gitlab/http_v2.rb:12:in `get'",
    "lib/gitlab/http.rb:32:in `public_send'",
    "lib/gitlab/http.rb:32:in `block (2 levels) in singleton class'",
    "ee/app/workers/observability/alert_query_worker.rb:45:in `fetch_alerts'",
    "ee/app/workers/observability/alert_query_worker.rb:18:in `perform'",
    "sentry-ruby (5.23.0) lib/sentry/cron/monitor_check_ins.rb:21:in `perform'",
    "vendor/gems/sidekiq/lib/sidekiq/processor.rb:220:in `execute_job'",
    "vendor/gems/sidekiq/lib/sidekiq/processor.rb:185:in `block (4 levels) in process'",
    "vendor/gems/sidekiq/lib/sidekiq/middleware/chain.rb:180:in `traverse'",
    "vendor/gems/sidekiq/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'",
    "ee/lib/gitlab/sidekiq_middleware/set_session/server.rb:21:in `call'",
    "vendor/gems/sidekiq/lib/sidekiq/middleware/chain.rb:182:in `traverse'",
    "vendor/gems/sidekiq/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'",
    "lib/gitlab/sidekiq_middleware/identity/restore.rb:12:in `call'",
    "vendor/gems/sidekiq/lib/sidekiq/middleware/chain.rb:182:in `traverse'",
    "vendor/gems/sidekiq/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'",
    "lib/gitlab/sidekiq_middleware/resource_usage_limit/middleware.rb:16:in `perform'",
    "lib/gitlab/sidekiq_middleware/resource_usage_limit/server.rb:8:in `call'",
    "vendor/gems/sidekiq/lib/sidekiq/middleware/chain.rb:182:in `traverse'",
    "vendor/gems/sidekiq/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'",
    ...
}

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

System information
System:   Debian 12
Proxy:    no
Current User: git
Using RVM:  no
Ruby Version: 3.2.5
Gem Version:  3.6.9
Bundler Version:2.6.9
Rake Version: 13.0.6
Redis Version:  7.2.9
Sidekiq Version:7.3.9
Go Version: unknown

GitLab information
Version:  18.1.0-ee
Revision: e0f3b86408a
Directory:  /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: PostgreSQL
DB Version: 16.8
URL:    https://gitlab.host.tld
HTTP Clone URL: https://gitlab.host.tld/some-group/some-project.git
SSH Clone URL:  git@gitlab.host.tld:some-group/some-project.git
Elasticsearch:  no
Geo:    no
Using LDAP: no
Using Omniauth: yes
Omniauth Providers:

GitLab Shell
Version:  14.42.0
Repository storages:
- default:  unix:/var/opt/gitlab/gitaly/gitaly.socket
GitLab Shell path:    /opt/gitlab/embedded/service/gitlab-shell

Gitaly
- default Address:  unix:/var/opt/gitlab/gitaly/gitaly.socket
- default Version:  18.1.0
- default Git Version:  2.49.0.gl2

Possible fixes

Looks like we are not properly validating the Elastic Search URL and not check if it is included into allowlist. For example, we do this for Kroki URL: https://gitlab.com/gitlab-org/gitlab/-/blob/v18.1.0-ee/app/models/application_setting.rb?ref_type=tags#L1217-1228

def parsed_kroki_url
  @parsed_kroki_url ||= Gitlab::HTTP_V2::UrlBlocker.validate!(
    kroki_url, schemes: %w[http https],
    enforce_sanitization: true,
    deny_all_requests_except_allowed: Gitlab::CurrentSettings.deny_all_requests_except_allowed?,
    outbound_local_requests_allowlist: Gitlab::CurrentSettings.outbound_local_requests_whitelist)[0]
rescue Gitlab::HTTP_V2::UrlBlocker::BlockedUrlError => e
  errors.add(
    :kroki_url,
    "is not valid. #{e}"
  )
end
Edited by 🤖 GitLab Bot 🤖