[UX Research] Desk research for job tokens

What did we learn

We ran a discovery exercise by auditing all tokens, reviewing CI_JOB_TOKEN features and authorization flow, and looking at past research. From this, we learned the following:

CI_JOB_TOKEN is preferred due to its ephemeral feature but is limiting for some use cases.

  • CI_JOB_TOKEN is preferred due to their ephemeral state which reduces the risk of credentials leaking
  • In cases where CI_JOB_TOKEN does not allow actions like pushing to other projects, customers will use other forms of less secure, static authentication like PATs or SSH
  • Terminology used to inform users of access actions like “limit” and “disable” is confusing to customers
  • Customers want CI_JOB_TOKEN to just work

Pipeline authorization use cases vary across organizations.

  • Use case for authorizing pipelines include:
    • project accessing its own resource
    • project accessing another project's resources, and
    • project is considered a shared resource and is accessed by many projects
      • Scalability concerns: Customers opt to disable securing token allowlist across projects for use cases where projects or group are considered shared resource

Features like auditability and traceability can help users with governing the use of CI_JOB_TOKENS in their organization

  • Customers seek to have a centralized global view for CI_JOB_TOKENS, trying to answer which projects have enabled allowlist features vs who is actually consuming projects based on the allowlist
  • Security auditors need to be able to audit the use of CI_JOB_TOKENS: most recent usage of the token, where the token was used, who triggered the token (person or bot), the specific action of the token (i.e. read from repo), who created the token
  • With the lack of tools available for auditing token use and settings within GitLab, customers have created their own tool to force projects comply with organization's policy on settings

For all tokens

  • GitLab has multiple token offerings, configuration of token are spread across the product with varying access rights and ability to configure scope.
  • Users run into difficulties with finding where to configure the tokens for their use case
  • Users felt uninformed and unprepared with the impacts of changing token features (eg automatic expiring tokens)

Gaps in research

  • Where is the best entry point for CI_JOB_TOKENS and all other tokens?
  • For use cases outlined above, is there ever a scenario where source and target is bi-directional?
  • With a new approach, how would customers expect to define project to project relationships, is it through membership? is it better suited to manage at a group or project level? What configurations need to sit at a group vs project level?
  • What other fine grained permissions are needed other than push?

Background

What’s this issue all about?

As part of the effort with &14655, this issue is to discover current experience, past research and customer problems related to job tokens. This issue is meant to capture and summarize existing data and provide direction on next steps for research.

Who is the target user of the feature?

Self Managed and SaaS users:

  • Security Operations Admin
  • Infrastructure Security Engineer
  • Software developer

What questions are you trying to answer?

  • What insights can be derived from existing token research?
  • What's the current experience with job tokens? And all other tokens offered by GitLab?
  • What are the use cases for job tokens token?

What decisions will you make based on the research findings?

  • This research will help with establishing foundational insights and determine gaps in research

What's the latest milestone that the research will still be useful to you?

%17.4

Checklist

Edited by Ilonah Pelaez