Draft: Add groups to CI_JOB_TOKEN allowlist POC
Original issue: #435903 (closed)
What does this MR do and why?
The current configuration for CI_JOB_TOKEN
permissions relies on the project allow list, where permitted projects can be specified. The primary objective of the original issue is to expand this functionality by enabling permissions for CI_JOB_TOKEN
on specific projects through group associations.
This is the POC of the issue: #435903 (closed).
Allow list implementation:
- Similar to
Ci::JobToken::ProjectScopeLink
, should be introducedCi::JobToken::GroupScopeLink
model/table,source_project_id
,target_group_id
- Extend
Ci::JobToken::Allowlist
to support with new methodsadd_group
andremove_group
and includes_in_projects_list?(target_project) - Inject to
Ci::JobToken::Scope
inbound_accessible?
method, a condition `group_accessible?(accessed_project) behind a feature flag - Implement
group_accessible
with the scope validation by matchingcurrent_group
ofcurrent_project
, withtarget_group
iterated fromCi::JobToken::GroupScopeLink
of the accessible project allow list, more details -
group_accessible?
group CI_JOB_TOKEN validation implementation:
The entire process of validating the CI_JOB_TOKEN
relies on the idea that we execute pipelines on the current_project and assess permissions to determine if we can reach the accessible_project through the CI_JOB_TOKEN
.
The process of confirming whether the current_project
can access the accesed_project
based on current_project
group operates like this: we construct a hierarchy of all parent groups on the current_project
, such as current_project_group1
-> current_project_parent_groupA_of_group1
, and if any of the current_project
groups in this list are on the allow list for the accessed_project
groups, access will be granted.
To avoid confusion here is the references between used terms as current_project
, accessed_project
, current_group
and codebase:
As we build the group allowlist following convention and naming used on project allowlist:
-
target_project
is acurrent_project
where we run a pipeline and validate if thiscurrent_project
could access anaccessed_project
usingCI_JOB_TOKEN
-
target_group
is a group oftarget_proejct
also the group field in the table of group allowlist -
source_project
is anaccessed_project
that we try to access from thetarget_proejct
and also the project field in the table of group allowlist, determines which project owns the current group allowlist.
API/GraphQL
- Introduce a mutation similar to
Mutations::Ci::JobTokenScope::AddProject
->Mutations::Ci::JobTokenScope::AddGroup
- Mutations::Ci::JobTokenScope::RemoveGroup
- Add CIJobToken group allow list field for GraphQL - or extend
Ci::JobTokenScopeType
with allow list groups list, similar tofield :inbound_allowlist
Per feedback: We probably need some method to automatically update reference links when things move around, especially in terms of group accesses. The concern here is the current implementation is static and it for enterprise users, it is highly likely that subgroups or project paths will change with re-organization. Having a way to detect and as an MVC provide error handling will at least notify users that a path is now broken.
For the initial MVP, I propose omitting this step. In the event of changes to subgroups or project paths, it is challenging to promptly notify users of potential broken paths. The current implementation automatically removes a project from the allowlist if it is deleted. I don't foresee scenarios where paths could break, except in cases of deleting a specific group. The lists of projects and subgroups will dynamically expose themselves based on the root group included in the allowlist.
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Numbered steps to set up and validate the change are strongly suggested.
Iteration plan
- Database design of group list table and model - job_token/group_scope_link - (MR: !142749 (merged))
- Add into
app/models/ci/job_token/group_scope_link.rb
andapp/models/ci/job_token/allowlist.rb
groups validation together with inbound lists, behind a feature flaggroup_scope_link_allowlist
- !142441 (merged) - GraphQL implementation (MR: !143132 (merged))
- REST API implementation
How to setup and validate locally iteration 2
How to set up and validate locally
- Enable a FF: ::Feature.enable(:ci_job_token_groups_allowlist)
- Create for example
private_source_project
on theprivate_source_group
- Create a
private_target_group
- Create a
private_target_project
in theprivate_target_group
- Generate an artifact on
private_source_project
by creating.gitlab-ci.yml
create_artifact:
script:
- echo "artifacts data" > artifact.txt
artifacts:
paths:
- artifact.txt
- Add manually a group into groups allowlist:
Ci::JobToken::GroupScopeLink.create(source_project: private_source_project, target_group: private_target_group, added_by: user)
- Run a pipeline on
private_target_project
with.gitlab-ci.yml
artifact_download:
script:
- echo "test 11"
- 'curl --location --output artifacts.zip "http://gdk.test:3000/api/v4/projects/47/jobs/10743/artifacts?job_token=$CI_JOB_TOKEN"'
- ls -la artifacts.zip
- unzip -p artifacts.zip | cat -
Screenshots
Before or FF is off | After and FF is ON |
---|---|
How to setup locally Iteration 3
-
Navigate to the grapqhl explorer
http://localhost:3000/-/graphql-explorer. # can be different based on gdk config
-
Copy and paste and run the following queries to the grqphql explorer to test
Fetching the lists of groups
# Fetching the lists of groups
query fetchGroupAllowlists {
project(fullPath: "flight/flightjsFlight") {
id
ciJobTokenScope {
groupsAllowlist {
edges {
node {
id
}
}
}
}
}
}
Response:
{
"data": {
"project": {
"id": "gid://gitlab/Project/38",
"ciJobTokenScope": {
"groupsAllowlist": {
"edges": [
{
"node": {
"id": "gid://gitlab/Group/87"
}
},
{
"node": {
"id": "gid://gitlab/Group/25"
}
}
]
}
}
}
}
}
Add a group to allow list
mutation addGroup {
ciJobTokenScopeAddGroup(
input: {
projectPath: "flight/flightjsFlight",
targetGroupPath: "new_group"
}
) {
errors,
clientMutationId,
ciJobTokenScope {
groupsAllowlist {
edges {
node {
id
}
}
}
}
}
}
Response:
{
"data": {
"ciJobTokenScopeAddGroup": {
"errors": [],
"clientMutationId": null,
"ciJobTokenScope": {
"groupsAllowlist": {
"edges": [
{
"node": {
"id": "gid://gitlab/Group/87"
}
},
{
"node": {
"id": "gid://gitlab/Group/27"
}
}
]
}
}
}
}
}
Remove a group from allow list
mutation removeGroup {
ciJobTokenScopeRemoveGroup(
input: {
projectPath: "flight/flightjsFlight",
targetGroupPath: "newgroup"
}
) {
errors,
clientMutationId,
ciJobTokenScope {
groupsAllowlist {
edges {
node {
id
}
}
}
}
}
}
Response:
{
"data": {
"ciJobTokenScopeRemoveGroup": {
"errors": [],
"clientMutationId": null,
"ciJobTokenScope": {
"groupsAllowlist": {
"edges": [
{
"node": {
"id": "gid://gitlab/Group/27"
}
}
]
}
}
}
}
}