Support member access rules with no group to apply to all eligible users

Summary

Allow admins to create a member access rule without selecting a specific group. This rule would apply to all eligible users in the instance (Self-Managed) or top-level namespace (GitLab.com), removing the need to create and maintain a dedicated catch-all group.

This was identified as the preferred solution direction in #591322 (see discussion).

Problem

Currently, once any group-based member access rule is configured, all Duo access is governed exclusively through those rules. Users not in an explicitly configured group lose access to all Duo features, including Classic features they were previously entitled to via Duo Core or Duo Enterprise seat assignment.

For example, if an admin creates a single rule granting a pilot group access to DAP, every other user in the instance loses Duo Classic access. The only workaround today is to:

  1. Create a separate group containing all users who should retain Classic access
  2. Add a second rule granting that group Classic access

This is burdensome, especially for large organizations (e.g., 17,000+ users) without LDAP/SAML group sync.

Proposal

Add the ability to create a member access rule with no group entry, representing "all eligible users." This rule would match:

  • Self-Managed: All users in the instance
  • GitLab.com: All members of the top-level namespace

"Eligible" means users who already have access through existing entitlement logic (Duo Core via Ultimate/Premium subscription, or Duo Enterprise/Professional seat assignment).

Example configuration

Group GitLab Duo Classic GitLab Duo Agent Platform
(All eligible users) ✅ ❌
pilot-users ✅ ✅

With this configuration:

  • All users who are already entitled to Duo (via Core or seat assignment) retain Classic access
  • Only members of pilot-users get DAP access
  • No manually maintained catch-all group is needed

UX considerations

  • The "Add group" flow in Settings > GitLab Duo > Member Access should allow saving a rule without selecting a group, or offer an explicit "All eligible users" option
  • This rule should be visually distinct in the table to make it clear it applies broadly
  • Only one such rule should be allowed per configuration (to avoid conflicting defaults)

Interaction with existing rules

Following the existing multiple group membership behavior, when a user matches both the default rule and a group-specific rule, they should receive the union of features from all matching rules.

Benefits

  • Removes the need for a catch-all group: Admins don't have to create and maintain a group containing all users
  • No dependency on LDAP/SAML: Works for customers without identity provider group sync
  • Non-breaking: Existing configurations with explicit groups continue to work as before. This adds a new option rather than changing current behavior
  • Supports phased rollouts: Admins can roll out DAP to specific groups while keeping Classic available to everyone
Edited by 🤖 GitLab Bot 🤖