Application setting to restrict CI/CD Catalog publishing to specific projects

Summary

Allow self-managed and GitLab Dedicated administrators to restrict which projects can publish components to the CI/CD Catalog through an application setting (allowlist).

Problem

Currently, any user with appropriate permissions can publish components to the CI/CD Catalog from any project. For enterprise customers, this creates governance challenges:

  • Central DevOps/platform teams cannot control what appears in their organization's Catalog
  • Engineers may publish components without proper security/compliance review
  • The Catalog can become cluttered with unapproved components that other users might mistakenly assume are officially sanctioned

This is particularly critical for self-managed and Dedicated customers who want to maintain a curated, trusted Catalog.

Proposal (MVC)

Add a new application setting ci_cd_catalog_projects_allowlist that enables administrators to specify which projects are authorized to publish components to the CI/CD Catalog.

Behavior:

  • When the allowlist is empty (default): All projects can publish (current behavior preserved)
  • When populated: Only projects whose full_path matches an entry in the allowlist can publish
  • Unauthorized projects receive an error message when attempting to publish

Implementation includes:

  1. New application setting storing allowed project paths as an array
  2. New "Catalog" section in Admin → CI/CD settings with a textarea for managing the allowlist
  3. Validation in Ci::Catalog::Resources::ReleaseService to enforce the allowlist during publishing
  4. Metrics like:
    1. Number of unique namespaces that are using this feature
    2. Number of components that were blocked by this setting

POC Reference

A working POC demonstrating this approach: !206904 (closed)

Customer Feedback on POC

  • ✅ Customers confirmed this feature would be helpful
  • 💡 Requested enhancement: Allow groups (not just projects) in the allowlist (so maybe wildcard projects paths)
  • 💡 Requested enhancement: Customizable error message with link to internal documentation

Additional Context

  • This addresses the needs of self-managed and Dedicated customers
  • For .com/SaaS, the related policy-based approach is being explored in #441102

Related

Edited by Furkan Ayhan