Provide Build-Artifacts per dedicated Read-Only Access
<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=16414) </details> <!--IssueSummary end--> ### Description While setting up our continuous deployment process with GitLab i stumbled over the following Problem. How to securely deploy the build-artifacts from the GitLab-instance to the application servers? Since we're seeking for a way to access our build-artifacts per infrastructure-automation, we're interested in a _read-only_ access of the artifacts. Currently this is not possible for two reasons: The Deploy-Keys grant a secure read-only access to the Git-repository via SSH, unfortunately these do not provide the build-artifacts. In opposite the Access-Tokens grant access to the API, which does provide the build-artifacts. Unfortunately these Access-Tokens contain **all** rights of their owner. We consider this being an insecure way to access the artifacts, since a leakage of the access-token grants the attacker full access to our GitLab-instance which is something we would like to avoid. The current workaround seems to be creating a "technical" guest user with limited rights, giving her read-only access to the given repositories. ### Proposal We would like to propose either - that there is some functionality introduced to limit the access-rights of Access-Tokens - preferable to specific repositories, - that access to the build-artifacts may be granted using the deploy key for the given repository _or_ - a third (beside main and the wiki) git-repository f.e. `project.artifacts.git` is introduced which may contain the versioned history of artifacts. ### Links / references /cc @nick.thomas - referencing to the support request 48262
issue