diff options
Diffstat (limited to 'doc/user/project/new_ci_build_permissions_model.md')
-rw-r--r-- | doc/user/project/new_ci_build_permissions_model.md | 13 |
1 files changed, 7 insertions, 6 deletions
diff --git a/doc/user/project/new_ci_build_permissions_model.md b/doc/user/project/new_ci_build_permissions_model.md index 6c3fa5eb463..c07c4099f22 100644 --- a/doc/user/project/new_ci_build_permissions_model.md +++ b/doc/user/project/new_ci_build_permissions_model.md @@ -28,10 +28,10 @@ The reasons to do it like that are: and maximizing security. With the new behavior, any job that is triggered by the user, is also marked -with their permissions. When a user does a `git push` or changes files through +with their read permissions. When a user does a `git push` or changes files through the web UI, a new pipeline will be usually created. This pipeline will be marked as created be the pusher (local push or via the UI) and any job created in this -pipeline will have the permissions of the pusher. +pipeline will have the read permissions of the pusher but not write permissions. This allows us to make it really easy to evaluate the access for all projects that have [Git submodules][gitsub] or are using container images that the pusher @@ -44,14 +44,14 @@ It is important to note that we have a few types of users: - **Administrators**: CI jobs created by Administrators will not have access to all GitLab projects, but only to projects and container images of projects - that the administrator is a member of.That means that if a project is either + that the administrator is a member of. That means that if a project is either public or internal users have access anyway, but if a project is private, the Administrator will have to be a member of it in order to have access to it via another project's job. - **External users**: CI jobs created by [external users](../permissions.md#external-users-permissions) will have access only to projects to which user has at least reporter access. This - rules out accessing all internal projects by default, + rules out accessing all internal projects by default. This allows us to make the CI and permission system more trustworthy. Let's consider the following scenario: @@ -67,9 +67,10 @@ Let's consider the following scenario: ## Job token -A unique job token is generated for each job and it allows the user to +A unique job token is generated for each job and provides the user read access all projects that would be normally accessible to the user creating that -job. +job. The unique job token does not have any write permissions, but there +is a [proposal to add support](https://gitlab.com/gitlab-org/gitlab-ce/issues/18106). We try to make sure that this token doesn't leak by: |