Track authentications via job token and show log in CI/CD job token settings

Original problem

As a maintainer of a project that still has the legacy permissive CI_JOB_TOKEN access, I want to be enable the new stricter access. However, I would like to know what is the impact of enabling this stricter access.

Is it possible to show in the CI/CD settings, a list of (recent) projects that used CI_JOB_TOKEN to access my project?

Proposal

Surface authentications via CI_JOB_TOKEN. The authentications log should show unique source projects authenticating using CI_JOB_TOKEN and their last authentication time.

The list must be paginated as it could contain a high number of entries.

Project owners, by inspecting the authentications log, can

• populate the allowlist by adding the source project directly in it or allowlisting the sub-group or group where it comes from.
• do nothing. The use is not interested in allowlisting this project however, given that the job token scope is disabled, the authorization is currently allowed. When the job token scope is enabled or enforced at instance-level, authorizations from this project will fail.

The authentications log is populated even if the job token scope is enabled. This information can be used to remove projects from the allowlist that have not been authenticated in a while.

Previous proposal

Previous proposal

Instead of building only a tool to surface authentication data we can use this data to automatically add the source project to the target project's allowlist if the job token scope is disabled.To minimize breaking changes we could log and automatically add projects to the job token allowlist. Have it run for 1-2 milestones. In the meantime notify users to check the allowlist and modify it accordingly. Afterwards we enable the job token scope for projects and notify users again. In the issue, rather than building a monitoring tool we build a migration tool by tapping into the cross-project authentications via CI_JOB_TOKEN.The logic should take in consideration the limit of 200 items in the allowlist. Either we check if we can increase the limit or we can have logic that "compacts" the new entries by adding the nearest group to the allowlist and remove the explicit projects.We should visually distinguish the projects added by automation vs manually by project owners (e.g. with a separate table column).

Only populate the allowlist automatically for projects that have job token scope DISABLED.

As we're building this out, it would be good to track how many of the projects are actually engaging in curating the list (approving/rejecting) and also if customers are rejecting our recommended allowlists.