The recommended CircleCI guidelines seem to be use environment variables for different environments.
PROD_AWS_ACCESS_KEY_ID #for prod deployments
DEV_AWS_ACCESS_KEY_ID #for dev deployments
However, there is no way to configure CircleCI to limit access to these variables at a branch level.
Thus any developer with write access to our git repository can modify the .circleci/config.yml and use the PROD_AWS_ACCESS_KEY_ID env variable to deploy dev/other malicious code to the production environment.
In fact, this can even happen by accident due to a dev potentially copy pasting some portion of the yaml code while editing.
This seems like a huge security issue and I am surprised CircleCI has no real workarounds/features in progress to address this.
It’d be interesting to see if any other CI providers have tackled what you perceive to be a security threat, but I would have thought that any dev that can write to your repo is already completely trusted.
If an administrator does not trust their developers to push to production, they should not put production keys in the environment of the builds. We are building new features that will help our users model deployment systems that live outside of their build/test workflows, but it is not a bug in our current system.
For strict segregation between those who can write code and the keys to production systems, the administrator should not put keys in an environment in which the code is executed.
In our current system this would mean:
Putting the deployment keys in a separate project that only specific users or administrators can access.
Maintaining a separate build configuration project that operates on the artifacts of your main CI builds.
We will soon release a feature to CircleCI Contexts that will let an administrator restrict execution only to certain groups of people. This new feature will be useful for teams that need to model segregation of duties between those who write code and those who deploy.