Deploy tokens allow to download (through git clone), or read the container registry images of a project without the need of having a user and a password. However, the current scopes do not allow users to grant push access to the Gitlab Container Registry or Package Registry.
As a workaround, users have been either using a project member's Personal Access Token, which is dangerous as all project members can access shared runners. Or, creating a dedicated, fake user for each project/group, which is difficult to maintain, costs money and can cause issues with LDAP, SSL for some customers.
"We are building images on a server separate from the GitLab CI, these servers need a secure way to handle tokens with push access to the container registry"
Existing scopes
read_repository: Allows read-only access to the repository
read_registry: Allows read-only access to the Container Registry
Proposal
Expand the scope of GitLab's Deploy tokens to writing to the GitLab Container Registry.
Scopes
read_repository: Allows read-only access to the repository
read_registry: Allows read-only access to the Container Registry
write_registry: Allows write access to the Container Registry
Iteration
This issue will focus on the Container Registry, #213566 (closed) will address adding new scopes for the Package Registry.
MR Breakdown
MR
Title
Aspects
1
Container Registry write access support with a Deploy Token
Thanks for the proposal. The main reason why we don't want to assign write permissions to a deploy token is that we want to track the "author" of any change. With PAT, you always have a user associated with it. With deploy tokens, you don't as they are project-related and not user-related.
This will make impossible to define who is the author of the change. At the moment, the "service account" is still the suggested solution.
From a user PoV there is no real difference between "this was pushed from a service user" and "this was pushed from a deploy token". I can see how the DB modelling is different, but the end result is similar.
I agree with Ash here.
It would be totally fine if Gitlab in the background created a service account for these sort of things.
It's not the service account per se that's problematic. The problematic thing is how it must be managed.
Only one person in our company have Gitlab administration as part of their work and only a few have that kind of access. So every project that needs a service account must turn to them creating delays and an unnecessary workload for that person. And only having one service account that everyone have access to would give people access to projects that they possibly should not have access to via that account.
Having an option in the project settings so that every project administrator can manage the permissions them selves cuts away all those problems.
I don't see much difference between deploy keys and tokens in this regard.
And since deploy keys allow write access to repository, the argument from Fabio does not seem correct or has already a big exception.
Having per project service accounts is not very good solution and write access for deploy keys would be very appreciated.
Write access for deploy keys does make sense to me at least initially, though it needs a bit more research to understand the auditing implications. For now I've added this to our backlog and we can get this prioritized and take a deeper look when we have some capacity to implement the solution.
Extremely useful feature! We have a lot of dev teams that uses their own CI systems like Jenkins, Teamcity and Bamboo and they don't want to move their CI processes to GitLab. But they want to use GitLab as Docker image registry and sometimes as VCS.
So I have to create external user for each team, add it to project and give Developer role to it.. This is not only very unhandy, but also causes some security risks due to Developer privileges (token owner can do something with code). Also AFAIR external users increase license cost.
Agree with @akhnin concerns. We are trying to find a solution for external CI systems as well to support our users not yet using GitLab CI. Creating another user for each team would use up more Ultimate Licenses and is not ideal to manage. Hopefully this feature gets prioritized to be worked or @rwky solution can be provided into future release.
Sadly this isn't a huge priority at our company right now. We're currently using a fake users and limiting who has access to the users access token. So if anyone else wants to make a MR go for it.
@KCErb we're planning on it, but not until %12.5 so if you want to contribute it before then that's a possibility. @erushton what do you think about technical feasibility?
I was hoping to hear back from @erushton and found a workaround in the meantime so this dropped off my radar :)
Given that 12.5 is relatively close and I have something that meets my needs I don't suppose I'll tackle this. But if it's a decent beginner / first-time project I could be swayed.
We have another usecase: we need to push from one project to another (within the same group). Currently, neither $CI_JOB_TOKEN, a deploy token or a PAT allow to push to another project's registry.
The reason is that we expose the docker registry to our users, but we don't want to let them access all images (e.g. unreleased ones, development variants, ...) so we currently have to pull, retag to local namespace and push from within the second project, and only expose the second project registry.
This workaround works, but only if we can predict the upstream project tags (e.g. "stable"), not specific versions. Being able to push directly to registry B from project A would solve our problem, and we'd prefer to avoid creating user accounts for this.
@jlenny you said you were considering for 12.5, but can you clarify what exactly ? Adding write_registry scope to PAT, deploy tokens or both ?
This is still an important item, but we are rebalancing our %12.5 release due to too many things currently having landed there. Rescheduling this for a future release will help us ensure that we have capacity in each release to deliver.
I'd recommend everyone here take a look at the discussion in #20416 around a more general solution to this problem. Would love to hear if that will work for you here, or if there are other considerations in play.
Tim Rizzichanged title from {-write_registry permission to Deploy Token-}s to Expand the scopes of GitLab's deploy tokens to allow reading and writing to the Package and Container Registries
changed title from {-write_registry permission to Deploy Token-}s to Expand the scopes of GitLab's deploy tokens to allow reading and writing to the Package and Container Registries
Tim Rizzichanged title from Expand the scopes of GitLab's deploy tokens to allow reading and writing to the Package and Container Registries to Utilize Deploy tokens to read and write to the GitLab Package and Container Registries
changed title from Expand the scopes of GitLab's deploy tokens to allow reading and writing to the Package and Container Registries to Utilize Deploy tokens to read and write to the GitLab Package and Container Registries
Tim Rizzichanged the descriptionCompare with previous version
Reviewing for 12.10: I still stand by the 3 weight, there are some unknowns and some technical planning to do from the BE perspective, and this may take a few MRs to implement (FE/BE/possible feature flags). It will also require security reviews which may lengthen the timeline.
Tim Rizzichanged title from Utilize Deploy tokens to read and write to the GitLab Package and Container Registries to Use Deploy tokens to read and write to the GitLab Package and Container Registries
changed title from Utilize Deploy tokens to read and write to the GitLab Package and Container Registries to Use Deploy tokens to read and write to the GitLab Package and Container Registries
This feature will need revisiting the authentication & authorization system on packages APIs and the service used for Container Registry authentication. This is not a trivial change.
As such, I would split this effort in smaller pieces. I am suggesting the following MRs plan:
Seeing how many MRs we have above, this issue should be planned on two milestones. For 12.10, I would aim to have MR 1. (+ 7.) included. MR 2., 3., 4., 5. and 6. should be planned for 13.0.
@10io Thank you creating the plan and the detailed breakdown. Are you open to reordering the list a bit? I ask just because of the priority for each integration. Can we prioritize the container registry first? Can we prioritize: 6,1,7,2,3,4,5?
The only thing I'm pointing here is that, I think that we will not be able to deliver the container registry side (MR6) and the package APIs side(MR1 or 2 or 3 or 4 or 5) for 12.10. One of these sides, will have to be planned for 13.0.
@10io OK - let's prioritize the Container Registry permissions in 12.10 and the package permissions in 13.0. I'll update this issue and create a new one.
@trizzi, seeing how quickly the container registry MR went, I think I will start on the package registry tokens in #213566 (closed) now too. If it's just as fast, there's a chance it could make 12.10 after all.
Tim Rizzichanged title from Use Deploy tokens to read and write to the GitLab Package and Container Registries to Use Deploy tokens to read and write to the GitLab Container Registry
changed title from Use Deploy tokens to read and write to the GitLab Package and Container Registries to Use Deploy tokens to read and write to the GitLab Container Registry
Tim Rizzichanged the descriptionCompare with previous version
I've created an MR that adds a write_registry scope to deploy tokens to allow for registry push access. I went with write_registry instead of write_container_registry because read_registry already exists for reading from the container registry, and it would be very difficult to change, so I'm keeping the naming similar to avoid confusion. When we add package registry access, we will use read_package_registry and write_package_registry.
The MR is mostly code complete, a few more tests need to be added and updated to the auth specs, and then the feature needs to be properly tested locally. But I will be submitting the MR to database and documentation review to get a head start on that side of the review process.
MR Statuses
!28958 (merged) - 80% complete, 75% confident (slightly lower confidence in case I run into other areas of code using deploy tokens that I was unaware of).
In the mix of all the various reviews, we missed that the security review was never completed, so this is back in review until the AppSec team has approved.