In https://gitlab.com/gitlab-org/gitlab-ce/issues/31591 we have project deploy tokens to allow read-only access to a project. Since many times projects are organized in groups, we can consider implementing tokens at group level.
Proposal
Group deploy tokens allow read-only access to any project in the group, same as project deploy tokens, even if it will be created after the token.
Tokens can then be exposed with a group variables to all the projects in the group.
Project level tokens should over-ride group level token
Moving from AWS ECS Registry to Gitlab. Lacking on this feature as we have about 10 projects deploying to one K8s cluster. Don't want to create 10 different secrets.
@brendan in the last few weeks we've had an influx of customers showing interest in this already popular issue. Any chance you could take another look and see if we might move this out of backlog any time soon?
@Antiarchitect I believe that even if you do create 10 different secrets, you wouldn't be able to use them on one physical machine since the key is used to log in to the whole repository. So if you have group/project1 and group/project2 and use deploy token from group/project1 to login to the registry on machine1 then you can't use deploy token from group/project2 since it will override the previous one.
I think this would be ~Release given that the intent of them is for tokens used when deploying to k8s clusters etc. I think the label is here as a carry over from when it was all one group of CI/CD
Hello checking back on this request. @erushton I don't think this issue is specifically related to deploying with k8s but rather just read access to a project using the deploy token. I think k8s was just one of the use cases.
Also to @jlenny any chance we can get this off the backlog?
Thanks for the ping @yofeldstein, I missed @erushton's response above since I wasn't @ mentioned. I've updated the labels here to be correct, and this would now land in @ogolowinski's area. I agree it would be great to prioritize this one, with 142 upvotes and it possibly being a relatively quick win we could do a lot of good. Pinging @dosuken123 and @ogolowinski for review and consideration to bring it forward.
This would really help us, at the moment we have to manually enable the deploy tokens for 50+ repos, even though they are all under a single group. Any ETA on this?
@mnichols1 Can we discuss this and prepare it for 12.7?
The idea (similar to what we discussed for feature flag groups) is that we create groups that hold a set of projects who share the deploy keys without having to copy it several times see #21765 (comment 233050207)
@darbyfrey this one will be an MVP for 12.7 so I would like to start grooming this to get it ready - any idea who can/will be assigned here?
@ogolowinski the description of this issue is vague at the moment and refers to another issue for what we're doing, but it's unclear to me which part of that issue is being referred to. Can you please groom this one so that it has a current, more specific proposal, and uses the complete feature template? Time is of the essence if we want to get this into %12.7 since scoping starts EOD tomorrow.