prevent secrets from being printed to cloud-init logs
2
votes
3
answers
1299
views
A
cloud-init
script needs to set environment variable values to contain secrets.
>**What specific syntax can be changed in the below to prevent the secret PASS
and PSS
from being printed in the cloud-init
logs?**
**CURRENT CODE:**
Here is an example of a section of a cloud-init script that is causing secrets to be written into the log files:
export PASS=$PSS
echo "export PASS='$PSS'" >> /etc/environment
echo "export PASS='$PSS'" >> /etc/bashrc
echo "export PASS='$PSS'" >> /etc/profile
**THE PROBLEM:**
The problem is that the current code shown above is printing the explicit values contained in the variables into the cloud-init logs. This means that, currently, the only way to protect the secrets is to lock down the logs and be hyper-vigilant about rotating secrets as much as possible.
**WHAT WE NEED:**
>**Is there a linux-native way to prevent secrets from being printed into the output and logs?**
We would like this to be agnostic with respect to tool and agnostic with respect to cloud. Meaning that we would like to avoid relying on a pipeline tool's secret obfuscation features, and we would also like for the secrets to be obscured whether this is running in AWS, or Azure, or any other cloud provider. We would like a linux/bash solution to this problem that is portable and agnostic.
We use RHEL-based images for all our linux instances, including pure-RHEL, and also including Amazon Linux 2 and CentOS.
**RESPONSES TO COMMENTS**
Per @falcajr
's questions, the cloud-init script begins with #!/bin/bash
and the problem persists whether or not set -e
is present in the script. The logs we are seeing the secrets in are the console output when the cloud init script runs, which no doubt is already stored someplace, and which we will have to store separately in our own automation system. This OP asks for a linux-native solution so that it should not matter where the destination is. For example if there were an obscureFromOutput()
function, we would be asking for something like the following except in valid syntax and not in the following made up pseudocode:
echo "export PASS='obscureFromOutput($PSS)'" >> /etc/environment
Per @Isaac
's comment, the PSS
is received as an input variable for the cloud-init script. We do not believe that it should matter that packer is currently the tool sending in the PSS
input variable because we would like a linux-native solution that will work just as well if we switch to ARM templates
or to cloud formation
or to any other tool. If you have a specific way of solving this problem this OP is requesting a specific solution.
We then tried @falcojr
's second suggestion to make each command look as follows, but the secrets are still showing up in the packer command line output which gets pushed into logs:
echo "export PASS='$PSS'" >> /etc/environment &> /dev/null
Are we using the correct syntax? Is there something else to try?
Asked by CodeMed
(5357 rep)
May 22, 2021, 12:01 AM
Last activity: Nov 10, 2023, 07:36 PM
Last activity: Nov 10, 2023, 07:36 PM