Skip to main content

Full Access Flow

Step 1: Authentication via Authentik (OIDC)​

The user logs in through Authentik. The portal reads sub, preferred_username, name, email, and groups from the OIDC userinfo endpoint and stores them in a server-side session. If the user already has an OpenBao entry, its email, name and sub are refreshed from that userinfo; a failed refresh is logged and does not block login.

Admin detection: if groups contains platform-admins, the Admin section is shown in the sidebar.

Step 2: API Key Generation​

When a user generates an API key:

  1. The portal generates a random 32-character base64url key
  2. The key is stored in OpenBao at ai-factory/data/apisix/<username>, which is the source of truth, together with the user's email, name and sub as of their last login
  3. An ExternalSecret and ApisixConsumer CRD are created in the apisix-dev namespace. ESO syncs the key from OpenBao into a Kubernetes Secret, which APISIX reads via key-auth

Step 3: Admin Grants Model Access​

When an admin saves access changes in the portal:

  1. OpenBao is updated first. allowed_models for the user is written as the source of truth
  2. The reconciler reads all model routes (labeled dev-portal/model=true) and patches the consumer-restriction whitelist on each ApisixRoute CRD to match OpenBao
Why two places?

Kubernetes ApisixRoute is the enforcement layer. APISIX reads it to allow or deny requests. OpenBao is the state layer. The portal reads it to show the user's catalog and the admin's access table.

Step 4: User Makes an API Request​

  1. The user sends a request with the apikey: <api-key> header
  2. APISIX's key-auth plugin verifies the key. Returns 401 if invalid
  3. APISIX's consumer-restriction plugin checks the route whitelist. Returns 403 if not allowed
  4. If both pass, the request is proxied to the upstream AI model