Sign in or sign up before continuing. Don't have an account yet? Register now to get started.
Register now
Dependency proxy does not support composite identities
## Problem The dependency proxy returns 404 errors when accessed by users with composite identities (e.g., bot/agent users that are not direct group members). This is because the `read_dependency_proxy` permission check in `GroupPolicy` requires the user to be a member of the group via `dependency_proxy_access_allowed`. ### Root Cause In `app/policies/group_policy.rb`, the `read_dependency_proxy` permission is gated by: ```ruby rule { all?(dependency_proxy_access_allowed, dependency_proxy_available) }.enable :read_dependency_proxy ``` The `dependency_proxy_access_allowed` condition checks if the user has direct group membership: ```ruby condition(:dependency_proxy_access_allowed) do access_level(for_any_session: true) >= GroupMember::GUEST end ``` This fails for composite identities (e.g., bot users) that should have access through their parent organization or other authorization mechanisms. ### Evidence Investigation on a GitLab Dedicated instance revealed: - A bot user receives 404 errors when pulling images via the dependency proxy - A regular user can successfully pull images from the same group - Both users are in the same organization, but the bot is not a direct group member - Console testing confirmed: `Ability.allowed?(bot_user, :read_dependency_proxy, group)` returns `false` while the regular user returns `true` ### Impact This prevents bot/agent users from accessing the dependency proxy, breaking CI/CD pipelines and automation workflows that rely on composite identities for authentication. ### Proposed Solution Update the `dependency_proxy_access_allowed` condition to support composite identities by checking organization-level access in addition to direct group membership. This aligns with how other features handle composite identities (see [composite identity documentation](https://docs.gitlab.com/development/ai_features/composite_identity/)). The fix should: 1. Check if the user has direct group membership (current behavior) 2. Also check if the user has access through their parent organization 3. Support other composite identity authorization mechanisms ### Related - Request for Help: https://gitlab.com/gitlab-com/request-for-help/-/work_items/4424 - Composite Identity Documentation: https://docs.gitlab.com/development/ai_features/composite_identity/
issue