Do not set -x for bash userdata

[myoung34]

I have issues

I'm submitting a...

• bug report
• feature request
• support request - read the FAQ first!
• kudos, thank you, warm fuzzy

What is the current behavior?

Using -x in bash shows all output, unintentional and intentional. Great for debugging, but also a good way to leak sensitive data.

Combined with almost every permissive/readonly policy allowing ec2:Get* that allows this to be seen easily by read-only users with no access to the instance/secret via the GetConsoleOutput ec2 call.

If this is a bug, how to reproduce? Please include a code sample if relevant.

  pre_userdata = <<EOF
FOO=$(aws ssm get-parameter --name /foo  --with-decryption | jq -r -j .Parameter.Value | base64 )
EOF

Output shows:

[  12.549112] cloud-init[3817]: Cloud-init v. 19.3-4.amzn2 running 'modules:final' at Mon, 18 Jan 2021 19:13:12 +0000. Up 12.50 seconds.
[   12.565390] cloud-init[3817]: ++ aws ssm get-parameter --name foo --with-decryption --region us-east-1
[   12.569549] cloud-init[3817]: ++ jq -r -j .Parameter.Value
[   12.571574] cloud-init[3817]: ++ base64
[   13.309150] cloud-init[3817]: + FOO=somethingsensitive

What's the expected behavior?

Userdata runs but does not show swallowed output $()

Are you able to fix this problem and submit a PR? Link here if you have already.

Yes.

Environment details

• Affected module version: latest
• OS: all
• Terraform version: all

Any other relevant info

[unixorn]

👍🏽, do not want default behavior to be "spew everything, including secrets"

[ldemailly]

Counter point, given

# ls -l /var/log/cloud-init-output.log 
-rw-r----- 1 root root 34723 Jul 20 17:55 /var/log/cloud-init-output.log

ie you have to be root to see the output, I think having removed -x just makes troubleshooting problems in pre userdata harder, and I missed this change in release notes, but fixed it easily by adding it back inside our script

[myoung34]

You can still set set -x in your userdata. However, by default -x is not ideal.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.