Skip to main content
Unlisted page
This page is unlisted. Search engines will not index it, and only users having a direct link can access it.
Version: 5.x

MTE API Relay on Google Cloud Platform

Introduction​

MTE API Relay protects HTTP traffic between server applications with two relays. Your service sends ordinary HTTP to an outbound relay, which encrypts each request and sends it to an inbound relay in front of the destination API. Both relays run the MTE API Relay image. v5 relays pair only with v5 relays; see Upgrading from v4.

Network Diagram​

MTE API Relay on Google Kubernetes Engine​

GKE Deployment

The outbound relay keeps its pairs in memory and needs no Redis. Only inbound replicas share pair state through Redis.

Deployment​

The v5 relay is the same container on GKE as anywhere else. Use the Kubernetes manifest in the on premise guide with the image 321186633847.dkr.ecr.us-east-1.amazonaws.com/customer/on-prem/mte-api-relay:5.0.5, or a copy of it in your Artifact Registry. It runs a control plane, a managed inbound worker, and a standalone outbound relay, with the image pull secret and the probes on port 9091.

Server Configuration​

The image sets COMPANY_NAME and LICENSE_KEY to a development license. Set both to your production license on every relay.

Routing lives in DOMAIN_MAP. The inbound relay uses ordinary entries; the outbound relay uses entries with outbound: true whose upstream is the inbound relay. The on premise guide walks through both.

Usage Guide​

Point your service at the outbound relay instead of the destination API, and keep the path and query the same. No special request headers are needed; the host your service uses selects the outbound entry. See the on premise usage guide.

Security​

Container Hardening​

  • Minimal base image. The runtime image uses Google's Distroless cc-debian12 base, with no shell, package manager, or general purpose OS utilities.
  • Multi stage build. Build tooling and source never ship in the final image; only the compiled binary is copied forward.
  • Unprivileged runtime. The container runs as the nonroot user.
  • Small listening surface. The image declares ports 8080 and 9091. The probe listener on 9091 opens unless PROBE_PORT=0.

Vulnerability Scanning​

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

You can also generate native scan evidence in GCP by enabling Artifact Registry vulnerability scanning (Container Analysis) on the image you run in GKE.

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, for example 5.0.5.

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 apply an update, reference the new tag in your GKE deployment manifests, on both relays of the chain.

Fault Recovery​

Relaunch the relay container. The outbound relay pairs with the inbound relay again on its next request.

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 and subscribed customers. For escalations, scan reports, or hardening documentation, contact Eclypses Support: