Add expirable token max expires in

Problem to solve

It is not uncommon in Enterprise Environments to has strict security policies related to password/tokens management. Among known password policies a very common one is: maximum validity.

The Personal Access/Deploy Tokens have support for expires at given date, but it is not possible as admin of the Gitlab instance to enforce a maximum validity date for the tokens.

Intended users

The Security Officer can expect from the Operations the possibility to configure a maximum duration for the Personal Access/Deploy Tokens can be given by the End User are creation time.

Further details

Increases security as in strict environments the creation of Personal Access/Deploy Tokens can be prohibited if no expire at is given.

Proposal

Add two new Application Settings personal_access_token_max_expires_in and deploy_token_max_expires_in that can be changed by the Gitlab Administrator from the Application Settings page or over API. The new values will be used to validate the new tokens at creation time and reject them if the given expires_at is after today + personal_access/delpoy_token_max_expires_in

Changing the application setting is a matter of transition from a state where there was no personal_access_token_max_expires_in provided to a state where is provided. The following scenarios can be observed:

• PAT has no expire_at defined then use create_at + personal_access_token_max_expires_in as value
• PAT has expire_at defined and expire_at is before now + personal_access_token_max_expires_in then use expire_at as value
• PAT has expire_at defined and expire_at is after now + personal_access_token_max_expires_in then use create_at + personal_access_token_max_expires_in as value

This would allow a smooth transition and would also cover the case the the admin will increase or decrease the value for personal_access_token_max_expires_in

Permissions and Security

The new Application Settings options are to be changed only by the Gitlab Administrators and will have Gitlab Instance wide effect.

Documentation

Documentation is covered by Issue #35550

Testing

The risk is how to handle already existing Tokens that are set to never expire or have a expire at date the is out of the new allowed range. Easiest approach is to consider the create_at + personal_access_token/deploy_max_expires_in as expires at date if given date for expires_at at creation time is beyond the max valid date.

What does success look like, and how can we measure that?

Solution is working as expected if creation of Personal Access/Deploy Tokens was as before as long as the expires_at date is not after create_at + personal_access_token/deploy_max_expires_in. If the expires_at date is after created_at + personal_access_token/date_max_expires_in then the creation will be reject with a message.

Links / references

Depends gitlab-ce#61753