Disable SSH

We have some fairly sensitive information stored in environment variables for our build plan (ex. API keys). They are masked in the the settings which is great; however, if a user opts to “Rebuild with SSH” then they have full access to the container environment, including those sensitive environment variables.

Is there a way to disable SSH for some/all users to avoid this security issue. We don’t want these environment variables accessible to every Github user. Alternatively, is there a better way to store these keys?

3 Likes

Hello @Brian-Triplett,

Any user with write capabilities will also have SSH access. We are working on providing this ability but it is currently not of high priority because any user with write permissions could theoretically also expose secrets via commands issues through the config.yml file.

You should not be at any greater risk by allowing SSH access to users that have write access to the environment.

2 Likes

That does makes sense.

Any advice on how you then go about storing sensitive data in a build? For example, what if we want to deploy to a service like Docker, AWS, etc. as part of the build and need to authenticate. We don’t necessarily want everyone with write access in the organization knowing the tokens, keys, passwords to authenticate with those services. We could store those in a key store but I still see the Circle job having to connect to that.

Is there a recommended best practice?

You can put sensitive data in env vars in the CircleCI config - once they are in there they cannot be viewed or edited. However, of course, someone could commit a change to echo secrets to the build stdout, so you need to prevent that from happening. A good first step is to ensure your deploy keys only have read access to your repos.

Some other CI systems have a scanning system to detect when a secret has been printed to stdout, and will star them out. However, I think this is a misleading security feature - any attacker worth their salt will know this, and will echo out in Base64/Rot13/etc, which are trivially reversible.

2 Likes

Hey @KyleTryon, what don’t you add permissions around the environment variables? For example, if a certain user triggers a job, only expose the environment variables that particular user has permission to access in the builds.

EDIT: It looks like this is achievable via contexts https://circleci.com/docs/2.0/contexts/#environment-variable-usage

It is a big security issue, every developer can see all the sensitive env variables by “Rerun job with ssh”

One thing you could try, if you particularly want to lock things down, is to use the API to kick off builds. It allows the addition of build parameters, which you could use for secrets that you don’t want to make accessible to the build:

https://circleci.com/docs/api/#trigger-a-new-job

This would mean that your secrets are not stored permanently in CircleCI storage and thus they cannot be read by another user with repo access.