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. 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.

    Example 1. Configure heimdall to allow only local TCP/IP “loopback” connections to be made.

    Makes actually only sense, if your reverse proxy/gateway, which communicates with Heimdall, runs on the same machine.

    proxy:
  host: 127.0.0.1

  • port: integer (optional)

    By making use of this property, you can specify the TCP port the heimdall should listen on. Defaults to 4455.

    Example 2. Configure heimdall to listen on port 4444 for incoming requests.
    proxy:
  port: 4444

  • timeout: Timeout (optional)

    Like written in the introduction of this section, Heimdall configures useful timeout defaults. You can however override this by making use of the timeout option and specifying the timeouts, you need. The read timeout is also used while waiting for the responses from the upstream service. Setting it to 0 will make forwarding the requests to the upstream service impossible.

    Example 3. Setting the read timeout to 1 second, write timeout to 2 seconds and the idle timeout to 1 minute.
    proxy:
  timeout:
    read: 1s
    write: 2s
    idle: 1m

  • buffer_limit: BufferLimit (optional)

    Read and write buffer limits (default to 4KB) for incoming requests and responses created by heimdall. You can however override this by making use of this property and specifying the limits you need.

    Example 4. Setting the read buffer size limit to 1MB and the write buffer size limit to 2KB.
    proxy:
  buffer_limit:
    read: 1MB
    write: 2KB

  • 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.

    Example 5. Possible CORS configuration
    proxy:
  cors:
    allowed_origins:
      - example.org
    allowed_methods:
      - HEAD
      - PATCH
    allow_credentials: true
    max_age: 10s

  • 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.

    Example 6. TLS configuration
    proxy:
  tls:
    key_store:
      path: /path/to/keystore.pem
      password: VerySecure!

  • trusted_proxies: string array (optional)

    Heimdall can make use of X-Forwarded-*, like X-Forwarded-For, X-Forwarded-Method, etc, or the Forwarded header sent by its clients and also forward some of these (X-Forwarded-For and Forwarded) 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, the Host HTTP header is usually used to return the requested host. But when you’re behind a proxy, the actual host may be stored in an X-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.
    Example 7. Enable the usage of headers mentioned above only for clients residing in the 192.168.1.0/24 network
    proxy:
  trusted_proxies:
    - 192.168.1.0/24

  • 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).
    Example 8. Configure verbose errors
    decision:
  respond:
    verbose: true
    Example 9. Use 404 Not Found for authentication and authorization errors
    decision:
  respond:
    with:
      authentication_error:
        code: 404
      authorization_error:
        code: 404

Last updated on Aug 7, 2023

Decision
Management