Skip to main content
Your environment may need firewall or web proxy rules to use Endor Labs. Traffic flows in two directions:
  • Egress: Connections from your environment to Endor Labs, such as users accessing the Endor Labs user interface or CI systems calling the API.
  • Ingress: Connections from Endor Labs to your environment, such as scans that access self-hosted source code management (SCM) systems or private artifact registries.

​
Egress rules

Allow outbound HTTPS connections from your environment to the following Endor Labs endpoints. docs.endorlabs.com and elprodoss.blob.core.windows.net don’t have static IP addresses. Allowlist these endpoints by domain name.
If you use Endor Labs with an EU tenant, use https://app.eu.endorlabs.com instead of https://app.endorlabs.com.
If you use Endor Labs with an EU tenant, use https://api.eu.endorlabs.com instead of https://api.endorlabs.com.
If you use Endor Labs with an EU tenant, use https://factory.eu.endorlabs.com instead of https://factory.endorlabs.com.
If you have configured integrations with third-party applications like Jira, you may need additional egress rules to complete that integration. Consult the documentation for those applications to add the required rules.
For better performance, the Endor Labs client, endorctl, may attempt to connect to dynamically managed Endor Labs cloud resources not listed above. Egress restrictions that prevent such connections will not limit Endor Labs’ functionality.

​
Toolchain download sources

Depending on the languages and ecosystems a scan encounters, endorctl downloads build toolchains and SDKs on demand from their official public sources. In a network-restricted environment, allow outbound HTTPS access to the domains for the ecosystems you scan, in addition to the Endor Labs endpoints above.
This list isn’t exhaustive. Endor Labs adds and updates supported toolchain versions over time, and some sources, such as package registries, resolve to many possible domains depending on your dependencies. If a scan fails with a download error for a domain not listed here, allow that domain and retry.

​
Ingress rules for restricted environments

Endor Labs scans use dynamic IP addresses by default. If your environment requires IP allowlisting for firewall rules, contact Endor Labs support to enable Network Address Translation (NAT), which routes this traffic through a static IP address. You need NAT IP allowlisting for:
  • Self-hosted source code management systems: Bitbucket Data Center or self-hosted GitLab instances behind a firewall that Endor Labs needs to access for organization sync and repository cloning.
  • IP-restricted cloud SCMs: Cloud-based source code management systems that enforce IP allowlisting for app installations and API access.
  • Self-hosted artifact registries: Private artifact repositories that Endor Labs needs to access during dependency resolution in monitoring scans.
  • IP-restricted webhook receivers: Webhook endpoints that accept traffic only from allowlisted IP addresses and need to receive notifications from Endor Labs.
When scans run within a private environment such as CI pipelines or Outpost-scheduled SCM App scans, NAT configuration is not required.

​
Configure NAT IP allowlisting

Endor Labs routes NATed traffic through the following static IP address for your tenant’s region. To enable NAT IP allowlisting for your tenant:
  1. Contact Endor Labs support to enable NATed network requests for your tenant.
  2. Configure firewall ingress rules to allow HTTPS (port 443) traffic from the NAT IP address for your tenant’s region to your internal resources.

​
Proxy configuration

If machines in your environment connect to the internet through a web proxy, you must also configure proxy settings for endorctl scans, CI runners, and REST API access. See Configure proxy server settings to set the required environment variables.