Summary
The Kubernetes auth plugin currently tries to preserve resourceNames-granular authorization for some search endpoints by filtering collection responses after the upstream query. When unreadable rows appear in a page, this can underfill paginated results.
Rather than implementing page backfill/refill, change the authorization model for search endpoints: require the caller to have the broad list verb for the searched resource in the workspace, and do not support resourceNames-granular authorization on search endpoints.
Motivation
Backfilling filtered search pages would require repeated upstream DB queries and extra Kubernetes SelfSubjectAccessReview calls while skipping unreadable rows to fill max_results. That adds cost and complexity for collection-oriented APIs.
Proposed behavior
For search endpoints that currently rely on response-side filtering:
- authorize the request only if the caller has broad
list access to the searched resource in the target workspace
- if broad
list access is missing, deny the search instead of partially filtering or backfilling results
- stop treating search APIs as
resourceNames-granular authorization surfaces
Candidate surfaces
SearchExperiments
SearchRegisteredModels
GET /api/2.0/mlflow/model-versions/search
GET /ajax-api/2.0/mlflow/model-versions/search
SearchEvaluationDatasets
SearchTraces
- GraphQL search equivalents such as
mlflowSearchModelVersions
Non-search collection APIs can be handled separately if we want the same policy there.
Current behavior
A caller with only name-scoped permissions can have the search accepted and then see rows filtered out of the current payload, which underfills the page.
Expected behavior
Search results should be available only to callers with broad list access for that resource/workspace. Callers with only resourceNames-scoped grants should receive an authorization failure for search endpoints rather than filtered or underfilled pages.
Notes
This keeps the fix narrow and avoids a refill loop across tracking-store queries and Kubernetes authorization checks.
Summary
The Kubernetes auth plugin currently tries to preserve
resourceNames-granular authorization for some search endpoints by filtering collection responses after the upstream query. When unreadable rows appear in a page, this can underfill paginated results.Rather than implementing page backfill/refill, change the authorization model for search endpoints: require the caller to have the broad
listverb for the searched resource in the workspace, and do not supportresourceNames-granular authorization on search endpoints.Motivation
Backfilling filtered search pages would require repeated upstream DB queries and extra Kubernetes
SelfSubjectAccessReviewcalls while skipping unreadable rows to fillmax_results. That adds cost and complexity for collection-oriented APIs.Proposed behavior
For search endpoints that currently rely on response-side filtering:
listaccess to the searched resource in the target workspacelistaccess is missing, deny the search instead of partially filtering or backfilling resultsresourceNames-granular authorization surfacesCandidate surfaces
SearchExperimentsSearchRegisteredModelsGET /api/2.0/mlflow/model-versions/searchGET /ajax-api/2.0/mlflow/model-versions/searchSearchEvaluationDatasetsSearchTracesmlflowSearchModelVersionsNon-search collection APIs can be handled separately if we want the same policy there.
Current behavior
A caller with only name-scoped permissions can have the search accepted and then see rows filtered out of the current payload, which underfills the page.
Expected behavior
Search results should be available only to callers with broad
listaccess for that resource/workspace. Callers with onlyresourceNames-scoped grants should receive an authorization failure for search endpoints rather than filtered or underfilled pages.Notes
This keeps the fix narrow and avoids a refill loop across tracking-store queries and Kubernetes authorization checks.