Limit what environment variables get used in a Docker container/BP step

Issue #17232 resolved
Ryan Bannon
created an issue


I have a question/concern regarding the use of SSH keys in BP. Here's the scenario:

Suppose that when a pipeline runs and all my tests within have passed, I like to tag the associated commit in Bitbucket. Naturally, this means my Docker container has to have a private key written to it, which is not a problem. I use the suggested technique of having an environment variable store the obfuscated key, then:

umask 077 - echo $MY_SSH_KEY | base64 --decode > ~/.ssh/id_rsa

So, no problem there. I now have the ability to push back to my repo. Great. But, here's the issue:

Now suppose I allow people to fork and make PRs. If I merge in an outside party's PR (after a review, obviously), I risk having malicious code in my repo. This code could, say, send all the environment variables in the Docker container within a unit test. So, some outside party could get my SSH key.


  • is there a way to limit what environment variables make it to what BP steps
  • if not, could this be an included feature...or...
  • maybe I'm on the wrong track all together?

Actually, one thing I just realized I could do is:

  • break the pipeline up into steps that have share a built artifact
  • in the step that does the test and build, the first line would be to erase the environment variable
  • the step that does the tagging would do the id_rsa write above (instead of erasing the environment variable)

Did I just solve my own problem?

Comments (3)

  1. Aneita Yang staff

    Hey @Ryan Bannon,

    Thanks for reaching out.

    We're currently working on the ability to let users scope variables to deployment environments (tracked using Bitbucket Deployments), so that certain variables can only be accessed by the production deployment step for example. Is this something that would suit your use case?

    I'm also not sure I totally understand your concern. Generally speaking, the purpose of creating PRs and reviewing code is so that malicious code does not get committed to your repository. In the case where after even after review, malicious code is committed to your repo, I'm not sure that scoped variables will necessarily solve the problem. It isn't possible to guarantee that the malicious code won't run in your step (where the variables are available) anyways.

  2. Ryan Bannon reporter


    It doesn't solve the problem, but can help limit potential issues. First, it's totally possible that a reviewed PR will still have malicious code in it, since it's reviewed by humans. And, yes, it's impossible to guarantee that malicious code won't run in a step. My concern was about eliminating one possible security concern: the exposure of a private Bitbucket SSH key, which I believe I have solved in my first post.

  3. Aneita Yang staff

    Yes, your suggestion in your first comment definitely eliminates one possible concern. I'll close this issue off given that you've figured out a way to eliminate your concern. Please feel free to reach out if you have any other suggestions.

    If you're interested in being able to scope variables to your deployment environment, you can follow issue #13676 as that piece will be covered as part of the work to support deployment permissions.

  4. Log in to comment