MTE API Relay on Google Cloud Platform

Introduction:

The MTE API Relay Container is a Go application that encodes and proxies HTTP payloads to another MTE API Relay Container, which decodes and proxies the request to another API Service. The Eclypses MTE is a compiled software library combining quantum-resistant algorithms with proprietary, patented techniques to encode data. MTE API Relay uses FIPS 140-3 validated, quantum-resistant data encryption technology to protect data before it is sent across an uncontrolled network.

Network Diagram

MTE API Relay on Google Kubernetes Engine

---

Server Configuration

MTE API Relay is configured using environment variables.

Using a DOMAIN_MAP (Recommended)

Interactive Builder

Use the DOMAIN_MAP Builder tool to configure your domains visually, validate your settings, and copy a ready-to-use DOMAIN_MAP value — no manual JSON editing required.

DOMAIN_MAP is a JSON object keyed by the Host header that arrives with each request.
The value for each key is a settings object that tells the proxy how to process the request.

Settings

Field	Type	Purpose
upstream	string	Full URL (http://localhost:8080, https://api.internal)
pass_through_routes	string[]	Paths that use standard HTTP proxy, without MTE encryption
outbound_token	string	Token that authorizes a request to be encoded and sent out.
client_id_secret	string	Legacy shared secret used by some auth layers

Examples

1. Single Proxy: Requests with Host header mte-api.company.com are decrypted and forwarded to http://internal-service. The /health route is proxied without MTE encoding/decoding.

{
  "mte-api.company.com": {
    "upstream": "http://internal-service",
    "client_id_secret": "8KeJmtuKweUhymNJmGHvGMrJCUtHxhQG",
    "pass_through_routes": ["/health"]
  }
}

2. Multi-service proxy that handles:

• Incoming encoded requests for billing.company.io, forwarding to http://billing-service with /ready and /live routes unencoded.
• Request to users.company.io that include the x-mte-outbound-token header will be encrypted and proxied to the url specified in the x-mte-upstream header.
• All other requests (any Host) are proxied to http://default-backend:8080 without encoding.

{
  "billing.company.io": {
    "upstream": "http://billing-service",
    "pass_through_routes": ["/ready", "/live"],
    "client_id_secret": "8KeJmtuKweUhymNJmGHvGMrJCUtHxhQG"
  },
  "users.company.io": {
    "outbound_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9"
  },
  "*": {
    "upstream": "http://default-backend:8080",
    "client_id_secret": "8KeJmtuKweUhymNJmGHvGMrJCUtHxhQG"
  }
}

Export as one-line env var:

export DOMAIN_MAP='{ "billing.company.io": { "upstream": "http://billing-service", "pass_through_routes": ["/ready", "/live"], "client_id_secret": "8KeJmtuKweUhymNJmGHvGMrJCUtHxhQG" }, "users.company.io": { "outbound_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9" }, "*": { "upstream": "http://default-backend:8080", "client_id_secret": "8KeJmtuKweUhymNJmGHvGMrJCUtHxhQG" } }'

Host header derivation

The Host header is taken directly from the authority component of the absolute URL used in the request.
For example, https://api.example.com/users/1 the authority is api.example.com (port 443 is implicit for HTTPS), so the Host header sent by the client is exactly:

Host: api.example.com

If the URL contains an explicit port (https://api.example.com:8443/users/1) the header becomes:

Host: api.example.com:8443

DOMAIN_MAP must therefore use the exact same string—domain only, or domain:port—to match the incoming Host header. Or, use a wildcard "*" to match any host.

Host Matching

MTE API Relay performs an exact match against the Host header (case-insensitive).
If an exact match is not found, it checks for a wildcard ("*").
If no match is found, the request is rejected with 404.

Using individual Environment Variables (Legacy)

Using these environment variables will result in the MTE API Relay being configured to only handle a single domain. This method is deprecated in favor of using the DOMAIN_MAP variable. If both are provided, DOMAIN_MAP will take precedence.

Example:

• UPSTREAM - Upstream API or service URL.
• CLIENT_ID_SECRET - Secret for signing client IDs (minimum 32 characters).
• PASS_THROUGH_ROUTES - Comma-separated list of routes proxied without encoding/decoding.
• OUTBOUND_TOKEN - Token for authenticating outbound requests.

UPSTREAM='https://api.my-company.com'
CLIENT_ID_SECRET='2DkV4DDabehO8cifDktdF9elKJL0CKrk'
PASS_THROUGH_ROUTES='/health,/version'
OUTBOUND_TOKEN='s3cr3tT0k3nV4lu3'

Additional Environment Variables

• PORT - Default: 8080.
• LOG_LEVEL - One of trace, debug, info, warning, error, panic, disabled. Default: info.
• HEADERS - A JSON string of additional headers to add to upstream requests.
• FORWARD_HOST_HEADER - Stamp X-Forwarded-Host on upstream requests. Default: true. See Forwarding Headers. Since 4.7.0

---

Usage Guide

To use MTE API Relay, simply redirect your application's HTTP requests to the Outbound Relay instance and include the required x-mte-* headers. The Outbound Relay will handle encoding the request, forwarding it to the Inbound Relay, and decoding the response before returning it to your application.

Outbound Request Headers

When sending a request to the Outbound Relay, include the following headers:

• x-mte-outbound-token: The outbound token configured in the Outbound Relay.
• x-mte-upstream: The URL of the upstream service, from the perspective of the Outbound Relay. It should be an Inbound Relay URL.

Example Request

Before using MTE API Relay, a normal HTTP request would look like this:

curl -X GET https://api.my-company.com/data

After setting up MTE API Relay, the request to the Outbound Relay would look like this:

curl -X GET https://outbound-relay.my-company.com/data \
  -H "x-mte-outbound-token: __YOUR_OUTBOUND_TOKEN__" \
  -H "x-mte-upstream: https://inbound-relay.my-company.com/data"

tip

• The x-mte-upstream header should point to the Inbound Relay URL, not directly to the backend service.
• Only the Domain portion of the URL needs to be updated. The path of the URL can remain the same.

---

Security

Container Hardening

MTE API Relay is built and hardened using the following practices:

• Minimal base image — The runtime image uses Google's Distroless cc-debian12 base. It contains only the application and its runtime dependencies — no shell, no package manager, and no general-purpose OS utilities — which dramatically reduces the attack surface.
• Multi-stage build — The application is compiled in a separate golang build stage. Build tooling and source never ship in the final image; only the compiled binary is copied forward.
• Non-root runtime — The container runs as a dedicated unprivileged user (nonroot). No root privileges are required at runtime.
• Minimal surface — Only port 8080 is exposed, and the image runs a single binary entrypoint.
• No persisted secrets — No sensitive data is stored in the container; all configuration is supplied at runtime via environment variables.

Vulnerability Scanning

Container images are scanned for known vulnerabilities with Docker Scout prior to publication to the Google Cloud Marketplace. Scan reports for the current image tag are available from Eclypses Support on request (see Support).

Customers can also generate their own native scan evidence within GCP by enabling Artifact Registry vulnerability scanning (Container Analysis) on the image they pull and run in GKE. This produces Container Analysis findings directly within your own Google Cloud project.

---

Maintenance

Release Cadence

Updated container images are published on an as-needed basis — when new features, dependency updates, or fixes warrant a release. Security patches are issued out-of-band as needed and are not tied to a fixed calendar cadence. Each release is versioned (see the image tag, e.g. 4.7.0) and distributed through the Google Cloud Marketplace.

Patch SLA

Eclypses' commitment for security patches:

• Critical vulnerabilities are addressed in a patched image within 30 days of confirmed disclosure.
• Lower-severity issues are addressed in a subsequent release.

To receive an updated image, pull the latest tag and update your GKE deployment manifest to reference it.

Fault Recovery

• Relaunch the Relay container; API Relays will automatically re-pair.

---

Support

MTE API Relay is a commercially supported product from Eclypses. Support and security-patch SLAs (including the 30-day critical-patch commitment described under Maintenance) are provided to licensed/subscribed customers. For escalations, scan reports, or hardening documentation, contact Eclypses Support:
📧 customer_support@eclypses.com
🕒 Monday–Friday, 8:00 AM–5:00 PM MST (excluding holidays)