Extend PAT expiration setting to GitLab.com

Problem to solve

We implemented PAT expiration for self-managed instances to allow Administrators to apply a required expiration to PATs. However, this leaves a gap for GitLab.com customers who do not have the same functionality. In order to properly manage access to a GitLab environment, Group Owners of group-managed accounts need the same tools to enforce specific compliance controls for credential rotation.

Further details

We understand from customers that credential rotation should be mandatory, but not disruptive. Setting an expiration for PATs should provide a smooth experience for rotating the credential without halting productivity.

This feature should apply only to group-managed accounts because users may not be subject to this type of policy or enforcement outside of their work contexts. Applying this type of expiration policy broadly could be too invasive for the wider GitLab community.

Proposal

Introduce a PAT Expiration setting to the Group-level for group-managed accounts. This could live in Settings -> General -> Permissions, LFS, 2FA view for now.

• This setting should default to the instance-level value
  • If no value is present, the default should be empty so that there's no expiration set
• If a value is set:
  • Existing tokens that have expired should generate a notification that the credential has expired, similar to !26351 (merged)
  • Stretch goal: 7 days before a PAT expires, warn the user one time via email (your PAT is about to expire) and emit an error every time the PAT is used.

For now, no additional implementation is necessary while we determine the next iteration.

Since !17344 (merged) introduces programmatic enforcement, we should work towards future iterations that permit flexibility to support non-disruptive, or "soft", enforcement.

Permissions and Security

Only Group Owners of group-managed accounts should be able to see and modify this setting.