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