docs: Clarify group entry scope and limits on the job token allowlist

What does this MR do?

Two changes to "Add a group or project to the job token allowlist": state what a group entry matches, and split the allowlist size limit into the two limits the code enforces.

Why

What a group entry matches

Ci::JobToken::Allowlist#includes_group? resolves a group entry against target_project.parent_groups, which is ObjectHierarchy(...).base_and_ancestors: the consuming project's own group plus every ancestor up to the root. One group entry therefore matches every project under that group at any depth, and because the match happens when the token is used, projects created later are covered with no allowlist change. spec/models/ci/job_token/allowlist_spec.rb pins the project, subgroup and root-group cases. The rule as stated is general to job token access, which is where includes_group? sits; what I observed was one path through it, a container registry pull, described under Testing.

The page does not say that. The closest is a sentence in the cross-project push section, "A group entry on the allowlist that includes the source project also satisfies this requirement", which states the conclusion for one case rather than the rule. Without the rule stated, the natural reading of "add groups and projects to the allowlist" is that you enumerate them, one entry per project and another when the next team arrives, and that is also the reading that runs into the 200-entry limit.

The limit

The page says "You must not have more than 200 groups and projects added to the allowlist", which reads as one cap across both kinds of entry. The code carries two independent constants: Ci::JobToken::GroupScopeLink::GROUP_LINK_LIMIT = 200, validated per source project with no direction, and Ci::JobToken::ProjectScopeLink::PROJECT_LINK_DIRECTIONAL_LIMIT = 200, validated per source project per direction. If the single number was a deliberate simplification, I would still suggest splitting it, because a group entry and a project entry do not compete for the same 200.

The project constant is directional, but this section documents the inbound allowlist, so the number that binds a reader here is 200 inbound project entries and the proposed wording says 200. Naming the direction would mean introducing "access direction" on a page that does not currently use the term. If you would rather have it named, or would rather the sentence point at the outbound limit as well, say which and I will rework it.

Testing

Verified on GitLab.com. A private project held an image and carried a single group entry on its job token allowlist, pointing at a sibling group. The consuming project was created nine seconds after that entry, two subgroup levels below the allowlisted group, and was never itself added to any allowlist. Its job token pulled the image. Removing the group entry, with the role and everything else unchanged, produced requested access to the resource is denied. Restoring the entry restored the pull.

Related issues

No issue tracks this gap. Two adjacent issues:

• #593562 is about policy precedence when a group entry and a project entry both match. Different problem, though it does incidentally confirm that group entries match member projects.
• #607321 adds a Team target to the same allowlist. It changes what you can put on the allowlist, not what a group entry matches, so the sentence added here holds either way.

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

AI-Generated Content Disclosure: This MR was prepared with assistance from Claude Code. The output has been reviewed for correctness, verified against source, and validated against the documentation style guide.