We have several environment variables set up for one of our pipelines. One of these variables has the name 'AWS_SECRET_ACCESS_KEY_PRODUCTION'. The name of this variable is being displayed on the BitBucket Pipeline Logs screen interspersed throughout the content. For example, here is a snippet from the log from the 'Build setup' section of the pipeline (some of the values have been obfuscated or replaced)
Build setupumask 000
+
GIT_LFS_SKIP_SMUDGE=1 git clone --branch="$AWS_SECRET_ACCESS_KEY_PRODUCTIONevelop" --$AWS_SECRET_ACCESS_KEY_PRODUCTIONepth 50 https://x-token-auth:$REPOSITORY_OAUTH_ACCESS_TOKEN@bitbucket.org/... $BUILD_DIR ;
...
Cloning into '/opt/atlassian/pipelines/agent/buil$AWS_SECRET_ACCESS_KEY_PRODUCTION'...
HEAD is now at 4e0$AWS_SECRET_ACCESS_KEY_PRODUCTIONbe4 Merge$AWS_SECRET_ACCESS_KEY_PRODUCTION in ...portion-of-branch-name.../$AWS_SECRET_ACCESS_KEY_PRODUCTION...rest-of-branch-name... (pull request #1)
+ chmo$AWS_SECRET_ACCESS_KEY_PRODUCTION 777 $BUILD_DIR
Why does the name of the env variable show up in the log output like this?
Hi @Jon Theis,
this is related to how our secured environment variables work. When you declare a secured environment variable $TEST with value "something" we will effectively replace any occurrence of "something" from your logs by $TEST.
Hi @Jeroen De Raedt. Thanks for the reply and the explanation of how secured environment variables work. However, the issue is that the variable name is being output in the logs in places where it is not being declared. For example, if you review the log output that I put in my question, you'll see that environment variable name are being output in the git command that BitBucket pipelines is running to clone the repo into the docker container before any of my build steps are running.
Is pipelines itself perhaps using the variable name "AWS_SECRET_ACCESS_KEY_PRODUCTION" and so I should not use a variable of the same name? If that is the case, is there a list of such variables somewhere we can refer to?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I understand the issue. As I said: the variable replacement is relatively naïve in the sense that it replaces any occurrences of the value of that variable (which is kinda intentional, because we actually can not predict where this secured variable will show up in the logs).
A side effect is that sometimes things can replaced by the variable name, if the variable value happens to match something in the logs.
From your example:
--branch="$AWS_SECRET_ACCESS_KEY_PRODUCTIONevelop"
If you declared a variable $AWS_SECRET_ACCESS_KEY_PRODUCTION with value `d` and your branch would have been called `develop`, this would indeed end up as `$AWS_SECRET_ACCESS_KEY_PRODUCTIONevelop` in the logs.
BTW, if your examples here included your actual secured variables, I would recommend changing them, to avoid any passwords being abused.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.