OpenShift AI dashboard puts a Go backend in front of Models-as-a-Service

Red Hat has detailed a Backend-for-Frontend architecture used by the Red Hat OpenShift AI dashboard to connect users with its Models-as-a-Service stack. The thin service, written in Go and co-deployed with the dashboard, gives the user interface one API surface while keeping browser clients away from gateway and Kubernetes APIs, according to Red Hat’s engineering account.

Why the extra layer exists

A direct browser-to-MaaS connection would cross origins, expose the front end to changes in upstream API schemas and duplicate authentication logic. The dashboard also needs information that a browser cannot safely discover on its own, including the OpenShift ingress domain and Kubernetes authorization data.

The Go service addresses those boundaries without becoming a second identity authority. It extracts the access token forwarded with a dashboard request, passes that token unchanged to the MaaS gateway and leaves validation and authorization to Authorino. Red Hat says the service keeps no token database, session store or signing keys.

At startup, the backend can read the cluster’s config.openshift.io/v1/Ingress resource and construct the MaaS gateway address. An explicit MAAS_API_URL setting takes priority, while failed discovery leaves the service running but causes MaaS endpoints to return errors when called. Red Hat says a future dedicated MaaS backend API will return the exact gateway URL because custom gateway hostnames can break the current ingress-domain assumption.

Stable contracts across services

The implementation separates HTTP handlers, repositories and clients. Repositories can combine responses from the MaaS API with Kubernetes checks, while the dashboard receives a consistent data-and-metadata envelope. Errors preserve their upstream HTTP status codes so the frontend does not need separate handling for the backend and gateway.

The MaaS backend is one of several domain-specific services inside the dashboard pod. Other dashboard components communicate with it over localhost; for example, the generative-AI backend can request ephemeral API keys for playground sessions without importing MaaS internals. Red Hat now documents those inter-service endpoints in a CONSUMERS.md contract after finding that unversioned HTTP schemas could silently break consumers.

What platform teams should take from it

This is an architectural disclosure rather than a new product release, but it clarifies how OpenShift AI’s self-service model layer is assembled. The design ties the dashboard to OpenShift ingress discovery, Authorino for gateway authorization, Red Hat Connectivity Link for stateless authentication and rate limiting, and OpenShift Service Mesh for Gateway API traffic routing.

The tradeoff is another service to deploy, monitor and debug. Red Hat’s guidance is correspondingly narrow: a BFF is useful where teams must avoid cross-origin calls, keep credentials out of browser code, compose multiple services or shield a UI from independently changing APIs—not for a simple CRUD front end.