Limit scope of environment variable visibility in CI steps

Build Environment
,
1

Hi,

I am looking into ways to make the CircleCI environment variables scope restricted as much as possible. This is partially driven by the Codecov incident earlier this year: https://about.codecov.io/security-update/

CircleCI offers the “context” approach described here: Using Contexts - CircleCI

From what I understand contexts are per job. Is my understanding correct?

I am planning to structure my yaml file so a “step” only have access to environment variable in a need to know basis. For example the Codecov step, which is part of a test job, should only have access to the codecov token. But because the context can be specified per job, it ends up having all the context’s env variables even though it only should have one.

I would also like to separate production and staging related workflows, so tokens cannot be exposed to the other environment.

Any suggestions on how to approach this?

Thanks,
Zsolt

2

Hi there @zbencz3 ,

Yes, you are right to think of contexts being injected only at the job level right now; We are not able to inject a particular context just for a step within a job itself.

As such, if you need to “restrict” a context to a series of steps, you can refactor it to be 1 specific job then?
Of course, the trade-off here is that you may need extra instrumentation between these refactored jobs now;
For example, we need to use workspaces (e.g., persist_to_workspace and attach_to_workspace) to “transfer” files generated from job A and used by job B.

In terms of separating contexts for environment-specific workflows, you may be interested to take a look at restricted contexts via security groups:
https://circleci.com/docs/2.0/contexts/#restrict-a-context-to-a-security-group-or-groups

By restricting your secrets (contexts) to specific GitHub teams, and ensuring only certain GitHub teams can push to production environment (by git branches, for example), you should be able to achieve some level of security around the secrets then.

In addition, you can also consider setting up a machine user on GitHub. For instance, we could make a machine user the only member in a GitHub team responsible for deploying to production. Then, contexts restricted to this GitHub team (security group) cannot be accessed by any other users, except for your org admin.

Hope this provides some next steps moving forward!

Happy to discuss further to bounce some ideas :slight_smile: