Package Registry Guest Access Control Enhancement

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

Enhance package registry access controls by extending the existing package_registry_access_level setting to support granular guest access permissions for private projects, providing alignment between GitLab.com and self-managed instances without introducing breaking changes.

Background

  • Currently, GitLab.com does not allow guest users to pull packages from private projects
  • Self-managed instances support this functionality via internal projects
  • Need to align behavior while respecting customer preferences and avoiding breaking changes
  • Performance considerations at scale are critical

Proposal

Extend the existing package_registry_access_level setting to include a new state:

  • Current states: DISABLED, PUBLIC
  • New state: ENABLED (allows project-viewable users, including guests, to pull packages)

Key Benefits

  1. No Breaking Changes

    • Maintains current default behavior for existing projects
    • Introduces new functionality as an opt-in feature
    • Eliminates need for complex migration planning

  2. Platform Flexibility

    • Leverages existing infrastructure
    • Maintains consistent behavior across GitLab.com and self-managed
    • Supports future extensibility for group-level controls

  3. Performance Considerations

    • Uses existing database schema
    • Minimal impact on query complexity
    • Scalable approach compared to feature flags

  4. Enhanced Control

    • Project-level granularity
    • Explicit opt-in for enhanced access
    • Clear security boundaries

Technical Implementation

Phase 1: Project Level

  1. UI Changes

    • Convert existing toggle to select dropdown
    • Options: Disabled, Public, Guest Pull
    • Clear documentation of each option's impact

  2. Backend Changes

    • Extend package_registry_access_level enum with ENABLED state
    • Update permission evaluation logic
    • Add new policy checks for guest access

Phase 2: Group Level

  1. Package Finder Updates

    • Enhance finders to respect new access level
    • Optimize queries for performance
    • Add caching where appropriate

  2. Group Policy Integration

    • Support inheritance rules
    • Maintain performance at scale
    • Consider future group-level toggle

Performance Considerations

  1. Database Impact

    • No schema changes required
    • Leverage existing indexes
    • Monitor query performance

  2. Caching Strategy

    • Utilize existing cache mechanisms
    • Consider additional caching layers
    • Plan for cache invalidation

Security Considerations

  1. Access Control

    • Maintain strict permission boundaries
    • Clear audit logging
    • Explicit opt-in only

  2. Visibility

    • Empty repository view for guests
    • Clear UI indicators of access levels
    • Audit trail of changes

Migration Path

  1. For GitLab.com

    • Default to current behavior
    • Allow opt-in via UI
    • No forced changes

  2. For Self-Managed

    • Maintain existing functionality
    • Provide upgrade path
    • Document new capabilities

Next Steps

  1. Technical Review

    • Review database impact
    • Assess caching strategy
    • Validate permission model

  2. Implementation Planning

    • Define implementation phases
    • Set performance benchmarks
    • Plan monitoring strategy

  3. Documentation

    • Update technical docs
    • Create UI/UX guidelines
    • Prepare admin guides

Questions to Address

  1. Performance impact at scale for large groups
  2. Caching strategy for permission checks
  3. Future group-level control requirements
  4. Monitoring and alerting needs
Edited by 🤖 GitLab Bot 🤖