proxy:
host: 172.17.0.2
tls:
key_store:
path: /path/to/keystore.pem
password: VerySecure!
timeout:
read: 1s
write: 2s
idle: 30s
connections_limit:
max_per_host: 20
max_idle: 100
max_idle_per_host: 10
buffer_limit:
read: 4KB
write: 10KB
trusted_proxies:
- 192.168.1.0/24
cors:
allowed_origins:
- example.org
allowed_methods:
- HEAD
- PATCH
allow_credentials: true
max_age: 10s
respond:
verbose: true
with:
authentication_error:
code: 404
authorization_error:
code: 404
Proxy
Proxy is one of the operating modes supported by Heimdall, used if you start Heimdall with heimdall serve proxy
. By default, Heimdall listens on 0.0.0.0:4455
endpoint for incoming requests in this mode of operation and also configures useful default timeouts, amount of possible upstream connections is active and idle state, as well as buffer limits. No other options are configured. You can, and should however adjust the configuration for your needs.
This service exposes only the proxy endpoint.
Configuration
The configuration of the Proxy endpoint can be adjusted in the proxy
property, which lives in the serve
property of heimdall’s configuration and supports the following properties.
host
: string (optional)By making use of this property, you can specify the TCP/IP address on which heimdall should listen for connections from client applications. The entry
0.0.0.0
allows listening for all IPv4 addresses.0.0.0.0
is also the default setting.port
: integer (optional)By making use of this property, you can specify the TCP port the heimdall should listen on. Defaults to
4455
.timeout
: Timeout (optional)By using this property you can override the default timeouts used by heimdall. Following properties are supported:
idle
: Duration (optional)The maximum amount of time to wait for the next request when keep-alive is enabled. If set to 0, the value of the
read
timeout is used. Defaults to 2 minutes. This value is also used for the maximum amount of time an idle (keep-alive) connection to the upstream will remain idle before closing itself.read
: Duration (optional)The absolute amount of time allowed to read the entire request, including body. Defaults to 5 seconds. The
read
timeout is also used while waiting for the responses from the upstream service. Here it specifies the amount of time to wait for a server’s response headers after fully writing the request (including its body, if any). Upon successful upgrade responses from the upstream service, this timeout is disabled, allowing e.g. for WebSockets proxying. Setting this property to 0s will disable the timeout.Setting this timout to 0 will make heimdall vulnerable to Slowloris attacks. write
: Duration (optional)The maximum duration before timing out writes of the response. Defaults to 10 seconds. Setting this property to 0s will disable the timeout. Compared to the
read
timeout, thewrite
timeout is not absolute and reset each time data is written to the output stream. This allows Server-Sent-Events and other unidirectional communication without the need to extend the timeout. As with theread
timeout, this timeout is disabled upon successful upgrade responses from the upstream service, allowing e.g. for WebSockets proxying.
buffer_limit
: BufferLimit (optional)Buffer limits for inbound requests and outbound responses. You can however override this by making use of this property and specifying the limits you need. Following configuration properties are supported:
connections_limit
: ConnectionsLimit (optional)Allowed connections limit per upstream service. Following limits can be configured:
max_per_host
: integer (optional)Limits the total number of connections per host, including connections in the dialing, active, and idle states. On limit violation, dials will block. Defaults to 0, which means there is no limit.
max_idle
: integer (optional)Controls the maximum number of idle (keep-alive) connections across all hosts. 0 means no limit. Defaults to 100.
max_idle_per_host
: integer (optional)Controls the maximum number of idle (keep-alive) connections per hosts. Defaults to 100. Cannot exceed the value of
max_idle
.
cors
: CORS (optional)CORS (Cross-Origin Resource Sharing) headers can be added and configured by making use of this option. This functionality allows for advanced security features to quickly be set. If CORS headers are set, then the Heimdall does not pass preflight requests neither to its pipeline, nor to the upstream service. Instead, the response will be generated and sent back to the client directly.
tls
: TLS (optional)By default, the Proxy endpoint accepts HTTP requests. Depending on your deployment scenario, you could require Heimdall to accept HTTPs requests only (which is highly recommended). You can do so by making use of this option.
trusted_proxies
: string array (optional)Heimdall can make use of
X-Forwarded-*
, likeX-Forwarded-For
,X-Forwarded-Method
, etc, or theForwarded
header sent by its clients and also forward some of these (X-Forwarded-For
andForwarded
) to the configured upstream services. However, since these headers can easily be spoofed, the usage of them is only possible, when the request comes from a trusted source. This is typically the case, when Heimdall is operated behind yet another proxy. For example, theHost
HTTP header is usually used to return the requested host. But when you’re behind a proxy, the actual host may be stored in anX-Forwarded-Host
header, which could, however, also be spoofed.Depending on your setup you may need to rely on the aforesaid headers. In such cases, you have to configure the
trusted_proxies
option and list the IPs, or IP ranges (CIDR notation) of your proxies in front of heimdall. If not configured, heimdall will not accept those headers from any client to prevent spoofing as it might result in privilege escalation.Please consider security implications when making use of this property. respond
: Respond (optional)By making use of this property you can instruct heimdall to preserve error information and provide it in the response body to the caller, as well as to use HTTP status codes deviating from those heimdall would usually use.
This mapping is only applicable if the HTTP status code is set by heimdall and not by the upstream service in the response to the proxied request. For that reason you cannot configure the mapping for the accepted
response (it will be ignored).
Last updated on Sep 25, 2023