GAP Documentation
GitHub Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Proxy (HTTP/HTTPS, SOCKS)

The platform support two protocols for proxying outgoing requests: SOCKS5 and HTTP/HTTPS (CONNECT method)

How to use the http/https proxy

Most client libraries will automatically use the proxy if passed through the following environment variables:

http_proxy=http://proxy.gap-system:3128

https_proxy=http://proxy.gap-system:3128

However, you MUST ensure that the proxy is only used for external requests. Using it for internal requests (calling other applications within the clusters) will only lead to increased overhead and more difficult debugging.

The HTTP/HTTPS proxy will NOT serve https requests over an insecure protocol. Some client libraries expect the proxy to do that, but it is not secure. HTTPS requests need to use the proxy as a “https” proxy, eg. use the CONNECT method to ensure end-to-end encryption, certificate validation, etc.

How to use the SOCKS5 proxy

Use the following endpoint as a SOCKS5 proxy in your application: socks5.gap-system:1080

Most client libraries will automatically use the proxy if passed through the following environment variables:

http_proxy=socks5h://socks5.gap-system:1080 or

https_proxy=socks5h://socks5.gap-system:1080

or

all_proxy=socks5h://socks5.gap-system:1080

However, you MUST ensure that the proxy is only used for external requests. Using it for internal requests (calling other applications within the clusters) will only lead to increased overhead and more difficult debugging. You can look into the no_proxy environment variable (eg. no_proxy="*.gservice.emarsys.net")

Reasons to use the proxy

  • Provide static outgoing IP addresses to certain external partners for whitelisting

  • Performance: the proxy can help with NAT-related issues where the client repeatedly opens connections to the same endpoint. The proxy code is also highly optimized with regards to connection and protocol handling.

  • Future security plans

IP addresses

Requests utilizing the proxy will be seen as coming from the following IP addresses:

EnvironmentAddresses
Staging35.198.64.228
35.242.242.80
35.234.117.175
Production34.89.173.3
35.246.249.205
34.89.137.140

Running workloads on nodes with whitelistable IPs

In some cases it may be inevitable to run some workloads on machines with static outgoing IPs. An example of this is if the protocol cannot use proxies and an external partner demands static addresses for whitelisting reasons. Please always consult the administrators if you need to run your workload with static outgoing IPs, as static addresses, by definition, are finite resources and capacity planning may be needed.

How to run your workload on nodes with whitelistable IPs

You need to patch the deployment, add a node selector for 2 special labels, as well as a toleration for a taint as seen below. The workloads will be visible on the same static addresses as the proxies:

EnvironmentAddresses
Staging35.198.64.228
35.242.242.80
35.234.117.175
Production34.89.173.3
35.246.249.205
34.89.137.140

Example patch file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-deployments-name
spec:
  template:
    spec:
      nodeSelector:
        role: whitelist
      tolerations:
        - key: "role"
          operator: "Equal"
          value: "whitelist"
          effect: "NoSchedule"