Is there a way to remove sensitive strings in plain text, such as the Okera database password, from the
env.sh file? For example:
Note: The original solution below is outdated as the Okera deployment method has changed. It is strongly recommended that customers leverage a solution such as Kubernetes secrets as described here.
This is a general systems administration issue that is usually solved by a site-preferred practice. We list a couple of common choices below.
The Deployment Manager reads the
/etc/okera/env.sh file at startup, so we must ensure any alternate approach won't disrupt this process. Our most straightforward choices are to set the value before the process starts or make sure only the process owner can read the file.
For the first approach, consider setting the value for OKERA_DB_PASSWORD by typing it in before launching the Deployment Manager:
$ IFS= read -rs PW < /dev/tty
$ export OKERA_DB_PASSWORD="$PW"
The first command exercises some arcane Unix knowledge. In short, it will accept user input and store it in the variable PW without echoing it to the display. The second line copies the value of PW to the property and exports it so the Deployment Manager can read it from the shell environment.
You can avoid this interactive step by restricting read permission on
/etc/okera/env.sh just to the file owner, i.e., the user who starts the Deployment Manager.
$ chmod 500 /etc/okera/env.sh
One quite popular method has you move only properties with sensitive values to a restricted file, which is then sourced before the Deployment Manager starts.
$ touch ~/okera.sh
$ chmod 500 ~/okera.sh
$ echo "export OKERA_DB_USERNAME=\"user123\"" >> ~/okera.sh
$ echo "export OKERA_DB_PASSWORD=\"password123\"" >> ~/okera.sh
$ . ~/okera.sh
Finally, you could add the source command near the beginning of the
/etc/okera/env.sh file to eliminate the interactive sourcing step. Bear in mind this file can be overwritten in an upgrade process and would have to be restored manually.