Sensitive data (passwords etc.) should not be placed directly in the configuration files.
Quite common approach is to use environment variables to do the trick: we assign sensitive data to the environment variables and use these variables later on in our configuration/scripts/code.
But this raises another question: how we should make assignment itself? Should we use for that just another script in which sensitive data is stored in plain text?
Below is the approach that I've been talking.
There is a really nice script out there - encpass.sh
What it allows to do is to store a secret in a reasonably safe way and retrieve it easily in a bash script.
But why only in a reasonably safe way?
Well, secrets are encrypted using symmetric keys and both values (secret + password) are stored in a hidden directory that can only be accessed by the user who run the script. It obviously doesn't protect from situations in which attacker has an access to the user's hidden directory (for example if an attacker has a root access).
This risk can be mitigated by securing access to the keys with an additional password. In such a case, before using the secret, user is asked to provide the password. Although it works good for manual use cases, can become cumbersome in case when automation is used (we get back to the original problem - how to store password in a secure way?).
After setting up secrets using encpass.sh we can have a configuration file named configuration.sh, that looks like this:
#!/bin/sh configuration_param1=data1 # not sensitive data source encpass.sh configuration_param2=$(get_secret bucket_name secret_name)
Then, in our script we use it like this:
#!/bin/sh source configuration.sh echo configuration_param1 echo configuration_param2
BTW: This approach can also be used with other languages, for example recently I've used it with Go - there is a script in bash which uses encpass.sh to decrypt the secrets and then exports them. Afterwards I can access environment variables from my Go code.
Top comments (0)