Optional: How MaaS is Configured Under the Hood

You have been using MaaS as a consumer: generating keys, calling endpoints, observing usage. But someone had to set all of this up. This optional section walks you through what the platform team configured before you arrived, and how the pieces connect.

The MaaS object model

MaaS is built on a set of Kubernetes custom resources. When the platform team exposes a model, they are creating and linking these objects:

MaaS Object Model and Governance diagram showing AITenant

  • AITenant - bootstraps an isolated MaaS tenant with its own namespace, auth policies, and RBAC. Each team or project gets one.

  • MaaSSubscription - the central resource that maps users and groups to models, and defines quota and rate limits. Every API key you generate is backed by a subscription.

  • MaaSAuthPolicy - authorizes specific users or groups to access model endpoints through the AI Gateway. It enforces the access rules at the HTTP level on every request.

  • MaaSModelRef - points to the actual inference server (an llm-d deployment, a vLLM runtime, or an external provider). The subscription references this to know where to route requests.

  • ExternalProvider / ExternalModel - when the backend is a cloud provider (OpenAI, Anthropic, Gemini), these resources configure the endpoint, credentials, and model name mapping. From the consumers perspective, calling an ExternalModel is identical to calling a self-hosted one.

Both MaaSSubscription (quota) AND MaaSAuthPolicy (access) must exist for a consumer to reach an endpoint. Creating a subscription without an auth policy gives you rate limits but no access. The UI’s "Create matching authorization policy" checkbox creates both at once.

Anatomy of a subscription

Anatomy of a MaaSSubscription showing CR properties

A MaaSSubscription has three key sections:

  • spec.groups / spec.users / spec.serviceAccounts - who this subscription applies to. Users inherit quota limits from every subscription they belong to; the highest-priority one wins when limits overlap.

  • spec.priority - a numeric value that determines which subscription takes precedence. The platform team at Fed Aura Capital follows this scheme:

    • 100 - production customer-facing apps, strict quotas, billed to the prod cost center

    • 50 - staging and pre-release validation

    • 0 - development and data science exploration (the default)

    • -10 - personal sandbox and tutorial access (lowest precedence)

  • spec.models and tokenLimits - which models the subscription covers and the rate limits per model: tokens per request and tokens per time window (RPM/TPM).

Use priority gaps (10, 20, 30…​) between your tiers so you can insert new levels later without renumbering everything.

How users, groups, and policies bind together

Subscription

When you made an API call in the previous exercise, the gateway evaluated your request like this:

  1. Your OIDC token arrived with your user identity and group membership.

  2. The gateway looked up which MaaSSubscriptions include your user or groups.

  3. It evaluated the subscription priority to determine your effective quota.

  4. It checked MaaSAuthPolicy to confirm you are authorized for the /v1/chat/completions endpoint on qwen3-235b-a22b.

  5. Your request was routed to the model. Usage was recorded against your key.

This all happened in milliseconds, invisibly. The reason it works reliably at scale is that the platform team defined it once as Kubernetes resources: version-controlled, auditable, and repeatable.