Skip to main content

Security Gaps

This document records identified security gaps in the platform's authentication and authorization flows. Each gap is a section with the date it was found. Gaps are not necessarily exploitable vulnerabilities — some are design questions, missing documentation, or deviations from the established platform pattern that require review.

ML-Agent: Missing Token Exchange Before Forwarding to Downstream — 2026-06-19​

Severity: High
Flow: ML Agent Auth — BFF to ML-Agent to Trino
Routes affected: GET /chatbot/trino/catalogs, GET /chatbot/trino/schemas/:catalog, GET /chatbot/trino/tables/:catalog/:schema, POST /chatbot/run-workflow-trino

The BFF validates the user JWT via validateJWT middleware but then forwards the user's original Authorization header directly to ML-Agent without performing a token exchange. This deviates from the documented platform pattern (Token Exchange and Data Access) which states:

The user's original session token is never forwarded to downstream services.

Risk: The user's Keycloak session token — scoped to the BFF client, not to ML-Agent — is exposed to ML-Agent. If ML-Agent further forwards this token to Trino, the token audience mismatch may cause silent fallback to a less-restricted auth path. If ML-Agent is compromised, it holds live session tokens.

Resolution required:

  • Determine whether ML-Agent performs its own exchange internally (which would mitigate the risk at the ML-Agent boundary)
  • If not: add exchangeTokenForBackendMiddleware(mlAgentAudience) to all four routes in src/routes/mlAgentRoute.js, following the pattern in trinoRoute.js

Legacy BasicAuth Client Active by Default — 2026-06-19​

Severity: High
Flow: src/clients/trinoClient.js
Env var: TRINO_AUTH_MODE (default: basic)

The default value of TRINO_AUTH_MODE is basic, meaning that unless explicitly set to oauth, the BFF uses the trinoClient.js BasicAuth client with TRINO_USER + TRINO_PASSWORD environment variables — a shared service account — for all Trino queries.

Under BasicAuth mode:

  • All queries run under the same Trino identity regardless of which user triggered them
  • X-Trino-User is not set to the real user
  • Ranger enforces policies for the service account only — per-user access controls do not apply
  • Audit logs in Ranger show the service account, not the end user

Risk: Any deployment where TRINO_AUTH_MODE is not explicitly set to oauth silently runs without per-user authorization enforcement.

Resolution required:

  • Change the default in src/config.js from basic to oauth
  • Add a startup warning or hard failure if TRINO_AUTH_MODE=basic is detected in a non-development environment
  • Confirm whether any active deployment still relies on basic mode and plan migration

Cube: Service Account Impersonation Privilege Not Confirmed — 2026-06-19​

Severity: Medium
Flow: Semantic Layer Auth — Ontology, Cube & Trino
Routes affected: All /ontology/v1/cube/* routes

Cube uses a shared service account for the Trino connection but sets the query identity to the real user (matching the Superset pattern). When the connection user and the query user differ, Trino requires the connecting service account to hold the impersonate privilege. It has not been confirmed that this privilege is granted in the Ranger seed policies.

Resolution required: Confirm the Cube service account has impersonate rights in the Ranger trinouser seed policy.

Cube: trino_user Claim Source Not Confirmed — 2026-06-19​

Severity: Low
Flow: Semantic Layer Auth — Ontology, Cube & Trino
Routes affected: All /ontology/v1/cube/* routes

The Ontology backend creates a trino_user claim in the Cube JWT from the incoming Keycloak token. The exact source claim (preferred_username, sub, or other) has not been confirmed. If it does not match the username format Ranger expects (synced from Keycloak every 15 minutes), all semantic layer queries would be denied.

Resolution required: Confirm which Keycloak claim is used as trino_user and verify it matches Ranger's user store.

ONTOLOGY_AUTH_DISABLED Bypass Has No Environment Guard — 2026-06-19​

Severity: Medium
Flow: Semantic Layer Auth — Ontology, Cube & Trino
Env var: ONTOLOGY_AUTH_DISABLED

Setting ONTOLOGY_AUTH_DISABLED=true in ontologyRoute.js disables token exchange for all ontology routes and forwards the raw user token to the Ontology backend. There is no guard that prevents this env var from being set in a production environment.

Risk: If accidentally set in production, all ontology requests bypass scoped token exchange. The user's session token (scoped to the BFF client) is forwarded directly to the Ontology backend, which may reject it (audience mismatch) or accept it depending on its validation strictness.

Resolution required:

  • Add a startup assertion that ONTOLOGY_AUTH_DISABLED is only permitted when NODE_ENV=development or a similar non-production flag is set
  • Add a visible warning log when the bypass is active

Trino Gateway Basic Auth Fallback: No Audit or Alerting — 2026-06-19​

Severity: Low
Flow: Trino Gateway Auth — BFF

The Trino Gateway is configured with a gateway preset user (credentials in trino-gw-basic-auth K8s secret) as a break-glass fallback. Use of this credential is indistinguishable from normal gateway traffic in Trino logs unless Ranger audit logging is configured to flag the gateway username specifically.

Risk: The break-glass path could be used (deliberately or accidentally) without detection.

Resolution required:

  • Confirm whether Ranger audit logging captures requests authenticated via BasicAuth
  • Add a Ranger policy that logs and alerts on any query or gateway management action performed as the gateway user
  • Document the intended use cases for the break-glass credential and who holds access to the secret