how developers run pipeline without access on .gitlab-ci.yml

Question

The .gitlab-ci.yml configuration file should not be exposed to any user with the "developer" rule since it might grant unwanted access to variables and infrastructure or make different kinds of exploiting behaviour or simply unwanted changes possible.

therefore, according to https://gitlab.com/secure-ci-config-poc/ci-configs, i made projects and pipelines; but if the user who pushes don't have reporter or developer or other high permissions on ci-configs project which contains all configurations, pipeline fails!!

Found errors in your .gitlab-ci.yml:

    Project `root/ci-configs` not found or access denied!

now, how can I fix this error?! so developers can run pipelines, but can not access the configuration files and .gitlab-ci.yml files?

Thanks All

Answer 1

You cannot stop users from reading the configuration. A user triggering a pipeline must have at least read access to the CI yaml file. However, secrets should never be stored in the YAML file, so read access should generally not be problematic.

You can prevent write access, but users triggering pipelines must be able to read all the configuration files. That is really the primary goal in securing your CI configurations -- preventing execution of malicious changes to the CI configuration.

if the user who pushes don't have reporter or developer or other high permissions on ci-configs project which contains all configurations, pipeline fails

The configuration project should have either public or internal visibility to avoid this problem, as described in the GitLab documentation:

If the configuration file is in a separate project, you can set more granular permissions. For example:

• Create a public project to host the configuration file.
• Give write permissions on the project only to users who are allowed to edit the file.

Then other users and projects can access the configuration file without being able to edit it.

(emphasis added)

If you absolutely needed the project to be set to private visibility, you might consider granting developer access, but creating protected branch rules that require maintainer access or higher to push changes.

Additional considerations

Even if you prevent access to writing changes to the CI configuration file, if the CI configuration executes any code written in the repository (say, for example running unit tests) then you really haven't solved any problems. Consider, for example, that malicious code can be embedded in test code!

It is possible to have a CI configuration that does not execute user code, but it's something you need to consider. If you need CI configurations to execute user-provided code (like running tests) then it's likely not very advantageous to protect your CI configuration in this way as a matter of securing your environment/variables.