Please change Gitlab CI/CD permissions model

Dear Gitlab devs,

I’m in a small company, trying to set up sane DevOps workflows and pipelines, preparing for growth. I chose Gitlab because it sells itself like the silver bullet for that. And I really like everything else about it. But I’m very frustrated with Gitlab’s permissions model, regarding CI/CD configuration.

The core problem is what I already explained 3 months ago: a job should be considered secure depending on who triggers it, not on where it is triggered.

Some problematic scenarios:

  1. You use an external cache system. To use it, you need a token. Your project is public, but the token is private.
    • With the current model, if you receive an external MR, it will not be able to use cache. Unless you make the token unprotected.
    • With the proposed model, an external MR wouldn’t produce a pipeline automatically. A core dev, after reviewing it and verifying it doesn’t contain malicious code, would trigger the pipeline manually, and the build would have cache.
  2. You have a meta-repo where you aggregate some sources that come from private repos. To access those repos, there’s a protected variable with a deploy key or token.
    • With current model, nobody (not even project admins) can open an MR able to access the remote code. Because MR pipelines just never have access to protected variables.
    • With the proposed model, any admin or dev could run an MR pipeline. Or a dev could open the MR and an admin could trigger the pipeline.
  3. You have a token that you use across a whole organization. You save it as a protected secret, group-wise. The group has both public and private repos.
    • To workaround the limitations of current model, you should declare some protected variables as unprotected. But then everybody in public projects could hack those variables. The only option left is to repeat the variable declaration, project by project, setting it as unprotected in private ones.
    • With the proposed model, anybody from the team would be able to do privileged pipelines in any repo, whereas anybody from outside the team could just run the jobs that don’t require access to secrets.

Permissions should be there to make things more secure, but by having this nonsense model, basically the only way to actually work is to completely disable them. Or to keep searching for an endless list of workarounds. Or to not use features such as MRs.

Seriously, friends. Every now and then I stumble with the same wall. Once and again. It’s becoming a real PITA. :man_facepalming: Can’t something be done for it? Am I just wrong and forgetting some feature that would fix these problems?

Thanks!