Proxy (HTTP/HTTPS, SOCKS)
The platform support two protocols for proxying outgoing requests: SOCKS5 and HTTP/HTTPS (CONNECT method)
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.
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")
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
Requests utilizing the proxy will be seen as coming from the following IP addresses:
| Environment | Addresses |
|---|---|
| Staging | 35.198.64.228 |
| 35.242.242.80 | |
| 35.234.117.175 | |
| Production | 34.89.173.3 |
| 35.246.249.205 | |
| 34.89.137.140 |
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.
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:
| Environment | Addresses |
|---|---|
| Staging | 35.198.64.228 |
| 35.242.242.80 | |
| 35.234.117.175 | |
| Production | 34.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"