[Fix] Proxy/Key Management: Honor team_member_permissions /key/list In /key/list Endpoint - #27026
Conversation
…n /key/list Endpoint When a team grants /key/list via team_member_permissions, non-admin members should see all keys for that team — same as a team admin. Previously the classification in list_keys() only checked admin status, so permitted members fell into the service-account-only path and could not see other members' personal keys. Routes those members into the full-visibility set.
Greptile SummaryThis PR fixes a bug where non-admin team members granted Confidence Score: 5/5Safe to merge — minimal, targeted fix with no backwards-incompatible changes, good test coverage, and correct interaction with the existing filter deduplication logic. No bugs or security issues found. The fix is additive-only (expands visibility for explicitly-permissioned members), correctly relies on the existing No files require special attention.
|
| Filename | Overview |
|---|---|
| litellm/proxy/management_endpoints/key_management_endpoints.py | Adds _get_team_ids_with_key_list_permission_from_objects helper and merges its result into admin_team_ids inside list_keys; logic is correct and _build_key_filter_conditions already excludes admin teams from the service-account-only path |
| tests/test_litellm/proxy/management_endpoints/test_key_management_endpoints.py | Adds 6 focused unit tests covering: permission-granted members classified in admin_team_ids, members without permission stay in member_team_ids, per-team granularity, admin path unaffected, and direct SQL filter shape validation |
Reviews (1): Last reviewed commit: "[Fix] Proxy/Key Management: Honor team_m..." | Re-trigger Greptile
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
…deleev-481c14 [Fix] Proxy/Key Management: Honor team_member_permissions /key/list In /key/list Endpoint
Relevant issues
Pre-Submission checklist
tests/test_litellm/directoryChanges
Bug
When a team grants
/key/listviateam_member_permissions, the UI documents that all team members can see all keys within the team. In practice they could not — non-admin members fell into the service-account-only path inlist_keys()and never saw other members' personal keys. Only admin team members and the master key got full visibility.Root cause
list_keys()inlitellm/proxy/management_endpoints/key_management_endpoints.pyclassified each of the caller's teams as either:admin_team_ids→ full key visibility for the team, ormember_team_ids→ only service-account keys (user_id IS NULL) visible.The classification only checked admin status.
team_member_permissions["/key/list"]was never consulted, so a permitted non-admin member always landed in the service-account-only branch.Fix
Added a small helper
_get_team_ids_with_key_list_permission_from_objects()that returns non-admin teams where the caller has/key/listpermission viateam_member_permissions.list_keys()merges those team IDs intoadmin_team_idsso the existing full-visibility filter path applies. Reuses existing helpers (_team_member_has_permission,_is_user_team_admin); no architectural change.Tests
6 new unit tests in
tests/test_litellm/proxy/management_endpoints/test_key_management_endpoints.py:test_list_keys_team_member_with_key_list_permission_sees_all_team_keys— bug-fix pin: team granting/key/listis classified as full-visibility.test_list_keys_team_member_without_key_list_permission_only_service_accounts— existing-behavior pin: member without permission still service-account-only.test_list_keys_team_member_with_permission_in_one_team_only— granular: per-team permission classification.test_list_keys_team_admin_unaffected_by_member_permission_logic— admin path unchanged.test_build_key_filter_conditions_full_visibility_team_includes_service_accounts— direct SQL filter check (nouser_idconstraint → service-account keys + other members' keys visible).test_build_key_filter_conditions_member_only_team_restricts_to_service_accounts— existing-behavior pin on the SQL filter shape.End-to-end verification against a live proxy: pre-fix the caller saw 2 of 3 expected keys (own + service-account, missing the other member's personal key); post-fix all 3 are returned. Adjacent-behavior checks (same caller in a control team without the permission, master-key admin path) continue to pass on both states.
Type
🐛 Bug Fix