Improve new CI job permissions model docs
This commit is contained in:
parent
40c9edf69e
commit
45d69889c5
|
@ -28,13 +28,13 @@ The reasons to do it like that are:
|
|||
With the new behavior, any job that is triggered by the user, is also marked
|
||||
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
|
||||
as created by the pusher (local push or via the UI) and any job created in this
|
||||
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
|
||||
would have access too. **The permission is granted only for time that job is
|
||||
running. The access is revoked after the job is finished.**
|
||||
would have access too. **The permission is granted only for the time that the job
|
||||
is running. The access is revoked after the job is finished.**
|
||||
|
||||
## Types of users
|
||||
|
||||
|
@ -74,7 +74,7 @@ We try to make sure that this token doesn't leak by:
|
|||
|
||||
1. Securing all API endpoints to not expose the job token.
|
||||
1. Masking the job token from job logs.
|
||||
1. Allowing to use the job token **only** when job is running.
|
||||
1. Granting permissions to the job token **only** when the job is running.
|
||||
|
||||
However, this brings a question about the Runners security. To make sure that
|
||||
this token doesn't leak, you should also make sure that you configure
|
||||
|
@ -86,12 +86,6 @@ your Runners in the most possible secure way, by avoiding the following:
|
|||
By using an insecure GitLab Runner configuration, you allow the rogue developers
|
||||
to steal the tokens of other jobs.
|
||||
|
||||
## Pipeline triggers
|
||||
|
||||
Since 9.0 [pipeline triggers][triggers] do support the new permission model.
|
||||
The new triggers do impersonate their associated user including their access
|
||||
to projects and their project permissions.
|
||||
|
||||
## Before GitLab 8.12
|
||||
|
||||
In versions before GitLab 8.12, all CI jobs would use the CI Runner's token
|
||||
|
@ -203,7 +197,7 @@ Container Registries for private projects.
|
|||
> **Notes:**
|
||||
>
|
||||
> - GitLab Runner versions prior to 1.8 don't incorporate the introduced changes
|
||||
> for permissions. This makes the `image:` directive to not work with private
|
||||
> for permissions. This makes the `image:` directive not work with private
|
||||
> projects automatically and it needs to be configured manually on Runner's host
|
||||
> with a predefined account (for example administrator's personal account with
|
||||
> access token created explicitly for this purpose). This issue is resolved with
|
||||
|
@ -227,11 +221,22 @@ test:
|
|||
- docker run $CI_REGISTRY/group/other-project:latest
|
||||
```
|
||||
|
||||
### Pipeline triggers
|
||||
|
||||
Since 9.0 [pipeline triggers][triggers] do support the new permission model.
|
||||
The new triggers do impersonate their associated user including their access
|
||||
to projects and their project permissions.
|
||||
|
||||
### API
|
||||
|
||||
GitLab API cannot be used via `CI_JOB_TOKEN` but there is a [proposal](https://gitlab.com/gitlab-org/gitlab-ce/issues/29566)
|
||||
to support it.
|
||||
|
||||
[job permissions]: ../permissions.md#job-permissions
|
||||
[comment]: https://gitlab.com/gitlab-org/gitlab-ce/issues/22484#note_16648302
|
||||
[gitsub]: ../../ci/git_submodules.md
|
||||
[https]: ../admin_area/settings/visibility_and_access_controls.md#enabled-git-access-protocols
|
||||
[triggers]: ../../ci/triggers/README.md
|
||||
[triggers]: ../../ci/triggers/README.md#ci-job-token
|
||||
[update-docs]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/update
|
||||
[workhorse]: https://gitlab.com/gitlab-org/gitlab-workhorse
|
||||
[jobenv]: ../../ci/variables/README.md#predefined-environment-variables
|
||||
|
|
Loading…
Reference in New Issue