CircleCI Ideas

Security Concern: Production Environmental Variables Exposure

Imagine I have different workflows for all my environments including production, I have different teams with different permissions, to be able to deploy into production I must put environmental variables into CircleCI (ex. AWS CLI Credentials, Db Credentials, ... etc), which would make it exposed to everyone regardless of the permissions they have, they can use it to alter anything in production and can turn to a security breach, that would prevent us from being accepted in any security audit and is a mean reason why we are leaving CircleCI to something else with all what CircleCI offers, also this is supported by other CICDs like AWS Code Build, GitLab, .... etc, where there is an internal agent not exposed to any of who have access to CircleCI, .yml or Container SSH, when you are able to implement this URGENT feature?, the ability to make some variables not seen by all who have access to CircleCI or .yml file

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Sep 19 2018
  • New
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    September 21, 2018 06:54

    Can you clarify what you mean by different teams with different permissions? The way the environment variables are set up is that we inject them into the running build where the code is executing - the model we're using is that those who can modify the code that executes at runtime (in this case, anyone with write access to the repository) could trivially extract any environment variables. For situations where you need to have secrets that should not be available to those modifying the code we have two solutions:

    1) Use a separate repository for deployments - the permission model in CircleCI is closely integrated with your version control provider (eg: GitHub and Bitbucket), so to fully segregate secrets away from those with access to the code you can set up a separate project. You can then deploy either by triggering deployment builds via the API from your code build or running some out-of-band process to trigger those deployments, depending on how automated you want the flow to be. Admittedly, this is not the most elegant solution, and we are have some plans to make it nicer, but this would give you an virtual "air gap" between those modifying the code and the production secrets.

    2) We are currently doing previews of a new feature that will soon launch where you can add security rules to contexts, restricting access to particular groups (eg: GitHub teams). Combining that with manual approval jobs (where the approver would need to be in in the team that has access to the context) or using a code-level control on branches or tags for who can trigger whatever your production build is (where the triggerer of the build is someone on the team with access to the protected context) would allow you to have only certain people get to execute jobs that have your production secrets present.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    September 21, 2018 12:37

    Every environment variable should have an optical list of branches that it applies to.  Then, other builds won't see that secret.  This would completely solve this problem.

    I think most organizations don't realize that this hole exists. 

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    November 15, 2018 19:16

    CCI-I-302 will solve this issue.