Network connectivity requirements

Reading time: 0 minute(s) (0 words)

This page includes the outbound access requirements for locally hosted Nobl9 agents and Internet Protocol (IP) addresses for Nobl9 alerts that must be allowed for inbound connections to operate in compliance with the existing firewall or IP address restrictions.

Outbound access for locally hosted Nobl9 agents

Obtaining the agent container image

Nobl9's agent image is published on Docker Hub. Your Kubernetes cluster or other container runtime requires access to the Docker Hub to pull the image. You can also pull the image to a locally hosted artifact image repository and run it from there.
TCP port 443 outbound to the following:

• Docker Hub

Obtaining the sloctl image

Nobl9's sloctl image is published on Docker Hub. You can leverage it to integrate Nobl9 in the CI/CD pipelines.

Nobl9 needs outbound TCP port 443 to the following:

• Docker Hub

AuthN/AuthZ concerns

When an agent data source is created (in the Nobl9 web application or the Nobl9 API, via sloctl or the Terraform provider), an OAuth2 credential is created, unique to that agent. These credentials consist of a Client ID and Client Secret, which can be viewed in the web application as part of the agent installation instructions—they are visible within the Kubernetes YAML or Docker command line examples.

This credential allows the agent instance to connect to Nobl9 over outbound HTTPS, identify itself, and obtain its query configurations from the Nobl9 Application.

Nobl9 agent container network requirements at runtime

Nobl9 agent needs outbound TCP port 443 to the following:

• Nobl9 Okta instance
  • This is an Amazon ALB. As such, the IP addresses may change over time.
• Nobl9 SaaS application
  • This is an Amazon ALB. As such, the IP addresses may change over time.
• the data source API URL that was configured when you created the agent in the Nobl9 UI (varies depending on data source tool or flavor and your configuration).

Nobl9 alerts

You can opt to set configure alerts in Nobl9 to a variety of systems, including popular incident management SaaS tools (for paging), ticketing systems, chat systems (for chatops), as well as a flexible and secure customizable webhook feature (for webhooks to your CI/CD system, for example).

You may choose to receive alerts from Nobl9 through a firewall you control. These alerts originate from a predictable set of IP addresses (Amazon Elastic IPs) you can list as allowed for inbound access to your network.

💻ip allowlist

IP addresses to include in your allowlist for secure access:

If you're using app.nobl9.com instance:

• 18.159.114.21
• 18.158.132.186
• 3.64.154.26

If you're using us1.nobl9.com instance:

• 34.121.54.120
• 34.123.193.191
• 34.134.71.10
• 35.192.105.150
• 35.225.248.37
• 35.226.78.175
• 104.198.44.161

Web proxies

The Nobl9 agent's web proxy support allows the agent to connect to internet endpoints like app.nobl9.com and accounts.nobl9.com in networks that require proxied internet traffic.

Some environments also have security policies that require traffic inspection to control against malicious activity.

The Nobl9 agent allows routing all network traffic through a web proxy, including communication with the Nobl9 APIs and data sources. The agent relies on the proxy configuration defined by standard environment variables:

• HTTP_PROXY is the proxy used for HTTP requests.

• HTTPS_PROXY is the proxy used for HTTPS requests.

• NO_PROXY is a string with comma-separated values. The values define hosts that must be excluded from proxying and must be as follows:

  • An IP address prefix: 1.2.3.4
  • An IP address prefix in the CIDR notation: 1.2.3.4/8
  • A domain name
  • A special DNS label: *
  • The IP address prefix and the domain name can also include a literal port number: 1.2.3.4:80. A domain name matches that name and all subdomains.
  • A domain name with a leading . matches subdomains only:
    For example, Foo.com matches Foo.com and Foo.com; .y.com matches x.y.com but not y.com.
  • A single asterisk * signifies that no proxying should be done. The best effort is made to parse the string; errors are ignored.

In most cases, it is desired to set the same address in both HTTP_PROXY and HTTPS_PROXY.