ServiceConfig: Proxy settings for accessing external networks

[naferok]

Problem

In the current implementation, OrbitalHQ instances running in private or restricted networks lack a standardized way to specify a proxy for accessing external networks (e.g., for fetching updates, calling APIs, or connecting to external databases). This forces the configuration of containers or external traffic handlers, which increases the workload on DevOps resources and complicates deployment and maintenance.

Idea/proposal

It is proposed to add a proxy settings section to the services.config file, enabling the service to connect to external resources through a specified proxy. This would include details such as the proxy address, port, and, if required, authentication credentials.

orbital/config/services.conf

services {
  moviedb { 
    url = "https://api.themoviedb.org"
    proxy {
      host = "proxy.example.com"
      port = 8080
      protocol = "https"
      credentials {
        username = "user"
        password = "pass"
      }
    }
  }
}

When OrbitalHQ sends an HTTP request to http://moviedb, the URL will be rewritten to https://api.themoviedb.org, and the request will be routed through the specified proxy at http://proxy.example.com:8080. If the proxy requires authentication, the provided username and password will be used to authenticate the request. The protocol field specifies that the proxy operates over HTTP

Use Cases

Private Corporate Networks: Services deployed in isolated environments (e.g., corporate data centers) can access external resources via a corporate proxy without requiring code changes.
Security and Control: Administrators can centrally manage service access to external networks by defining proxy settings in the configuration, simplifying compliance with security policies.
Deployment Flexibility: Developers can quickly adapt the service to different environments (local, test, production) with varying proxy servers by simply updating the configuration file.
Cloud Service Integration: Services in private networks can securely interact with public cloud APIs through a configured proxy.

[martypitt]

Thanks for this, and for the detailed submission! 👍

This makes sense, and is something we could look at -- is there an current use-case where this would get used?