Using secrets in PRs for regular contributors (non maintainers)

[abravalheri]

Hello,

I currently use CirrusCI for the majority of my opensource projects and I have been very happy with it.

However, recently I stumbled across a dilemma:

There are some integration services that require secrets (e.g. access tokens) to be set in the CI environment (one example of such services is coveralls) to be able to work.
Cirrus CI support for secrets via env vars works fine for the majority of cases, however when regular contributors (without direct write access) submit PRs, these variables cannot be read and therefore some integrations cannot run.

It is a difficult problem since it involves security risks, but I was wondering if anyone knows if there is any best practice/way around this problem...

[fkorotkov]

You are a right it's a tough one from the security perspective. If you are OK to have the Coverall token to be at a potential risk you can add it as plain text in your repository settings:

This way the token will be visible in the settings only for people with write access to the repository. But still there might be a PR that does echo $COVERALLS_REPO_TOKEN to still the token.

On the other hand we might add a new policy beside Only users with write access and call it Only users with write access and collaborators. But still the first PR from a user won't have the token decrypted in this case.

[abravalheri]

Thank you very much @fkorotkov for the clarification.

Do you know if is there anyway of preventing cirrus-ci of running if the .cirrus-ci.yml file is changed by a person that does not have write access (non-maintainers)? (I suppose that is the easiest solution in terms of security right? Requiring maintainers to manually verify a PR before triggering Cirrus CI if .cirrus-ci.yml is changed...)

[fkorotkov]

Problem with changes to .cirrus.yml is that many people abstract their CI logic in separate scripts, for example, test.sh. And a bad actor can change test.sh instead of .cirrus.yml. I've thought about the issue for quite a while and it seems there is single solution for the problem.

But if all of your logic is in .cirrus.yml, you can config resolution strategy to Latest from the default branch so Cirrus will always use .cirrus.yml from the default branch and will ignore any changes to .cirrus.yml in a PR until it's merged.

[abravalheri]

Thank you very much @fkorotkov for the tip. That is very useful and I imagine can be used in conjunction with you previous tip to workaround the security limitations).

[abravalheri]

@fkorotkov, just to confirm: when an environment variable is overwritten in Cirrus Web UI (as per the image you posted), the visibility of its value is the same visibility of secured variables, right? So they work as secured variables, but without being encrypted?

Is there a way of specifying who can read each variable individually (i.e. have a variable that can be read by everyone and have variables that can be read just by people with write rights)?

[fkorotkov]

These overrides are added as is. The only difference is that it's not in YAML as plain text. You can use ENCRYPTED[...] syntax there to secure the value from non contributors like COVERALL_TOKEN=ENCRYPTED[...].