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 Relay Server on Google Cloud Platform

Introduction​

MTE Relay Server is a proxy that runs in front of your backend. Client applications use an MTE Relay client library to send encrypted requests; the relay decrypts each one, forwards the plaintext request to your backend, and encrypts the response on the way back. v5 relays serve only v5 clients; see Upgrading from v4.

Customer Deployment​

MTE Relay Server typically decrypts HTTP requests from a web or mobile application and forwards them to the intended API. On GCP, run the relay container in a Google Kubernetes Engine (GKE) cluster, as one or more replicas.

A typical customer already has, or plans to build:

  • A web application or a mobile application.
  • An HTTP API backend.

Network Diagram​

MTE Relay Server on Google Kubernetes Engine​

GKE Deployment

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-relay-server:5.0.5, or a copy of it in your Artifact Registry. It runs a control plane and a worker, with the image pull secret and the probes on port 9091, and the guide covers adding Redis for two or more workers.

Server Configuration​

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

MTE Relay Server is configured with environment variables. A standalone relay needs DOMAIN_MAP; a relay managed by the control plane needs CONTROL_PLANE_URL and CONTROL_PLANE_TOKEN instead.

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

Fault Recovery​

Relaunch the relay container. Without Redis, pair state lives in memory, so clients must authenticate and pair again after a restart. The browser engine does this when a request gets 475 invalid_client_id, but that request still fails with an MteRelayError marked repaired, and your code decides whether to send it again.

Support​

MTE Relay Server 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: