Commit 039415c8 authored by Achilleas Pipinellis's avatar Achilleas Pipinellis Committed by Kamil Trzcinski

Move document on CI build permissions to new location

parent 1e911e05
......@@ -20,3 +20,4 @@
- [Access dependent projects](dependent_projects/README.md)
- [API](../api/ci/README.md)
- [CI services (linked docker containers)](services/README.md)
- [**New CI build permissions model**](../user/project/new_ci_build_permissions_model.md)
......@@ -143,13 +143,11 @@ instance and project. In addition, all admins can use the admin interface under
> Changed in GitLab 8.12.
GitLab 8.12 has completely redesigned build permission system.
You can find all discussion and all our concerns when choosing the current approach:
https://gitlab.com/gitlab-org/gitlab-ce/issues/18994
GitLab 8.12 has a completely redesigned build permission system.
Read all about the [new model and its implications][new-mod].
### Build privileges
This table shows granted privileges for builds triggered by specific types of users:
This table shows granted privileges for builds triggered by specific types of
users:
| Action | Guest, Reporter | Developer | Master | Admin |
|---------------------------------------------|-----------------|-------------|----------|--------|
......@@ -168,4 +166,5 @@ This table shows granted privileges for builds triggered by specific types of us
[^3]: Only if user is not external one.
[^4]: Only if user is a member of the project.
[ce-18994]: https://gitlab.com/gitlab-org/gitlab-ce/issues/18994
[new-mod]: project/new_ci_build_permissions_model.md
# New CI build permission model
# New CI build permissions model
> Introduced in GitLab 8.12.
GitLab 8.12 has a completely redesigned build permission system. You can find
GitLab 8.12 has a completely redesigned [build permissions] system. You can find
all discussion and all our concerns when choosing the current approach in issue
[#18994](https://gitlab.com/gitlab-org/gitlab-ce/issues/18994).
......@@ -107,13 +107,12 @@ to checkout project sources.
The project's Runner's token was a token that you could find under the
project's **Settings > CI/CD Pipelines** and was limited to access only that
project.
It could be used for registering new specific Runners assigned to the project
and to checkout project sources.
It could also be used with the GitLab Container Registry for that project,
allowing pulling and pushing Docker images from within the CI build.
The project's Runner's token was used for registering new specific Runners
assigned to project and to checkout project sources.
The project Runners token could also be used with the GitLab Container Registry
for that project, allowing pulling and pushing Docker images from within the
CI build.
---
GitLab would create a special checkout URL like:
......@@ -128,7 +127,7 @@ commands to interact with GitLab Container Registry. For example:
docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com
```
Using single token had multiple security implications
Using single token had multiple security implications:
- The token would be readable to anyone who had developer access to a project
that could run CI builds, allowing the developer to register any specific
......@@ -279,3 +278,4 @@ test:
```
[git-scm]: https://git-scm.com/book/en/v2/Git-Tools-Submodules
[build permissions]: ../permissions.md#builds-permissions
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment