Using AWS System Manager Parameter Store SecureString in config file in ec2

Question

On an ec2 box I am running a service that reads vars from a config file. One var's value is stored in AWS System Manager as a SecureString. I want to use that value in the text file securely.

I can export the value via the cli with aws ssm get parameter --decryption and use that plain text value in a placeholder var called PASS and use that as the value in the config file. But then anyone with access to the box can call the same cli command and see the value.

The ec2 box has one user with an IAM instance profile letting them access the System Manager service.

What is the secure way to do use a SecureString value in a text file?

Answer 1

There's no way to keep secret that which you need in plain text; however, there are other strategies that can be combined to limit exposure of the 3rd-party program's static secret...

1. auth'd user connects to ec2 host via ssh
2. user obtains encrypted static secret E_secret from the param store/ equiv.
3. user launches a script as eg. user3p via sudo, providing E_secret somehow
4. script decrypts E_secret using some mechanism that it holds to obtain SECRET_3p, then destroys E_secret
5. script re-creates config file as securely as possible, destroys SECRET_3p, then launches 3rd-party program prog3p
6. prog3p runs under user3p and does its thing
7. script destroys the new config file, cleans up, and exits

That is the general gist of it. I'll describe each step briefly in subsequent paragraphs.

I assume that your user/s connect to a terminal on the aws ec2 instance using ssh. This strategy requires configuring sudo to run a script as another user fra-san'18. Don't configure sudo to allow the user to gain root privileges or this proposal won't work for obvious reasons!

Ed. I assume that the attached volume of the ec2 instance is also secured, otherwise this would be another vector of attack: the iam-profile attached to the ec2-instance must adhere to least privilege (eg. read from the param store only), among other things!

Your auth'd user connects to the param store and obtains E_secret. This will need to have been created previously from SECRET_3p using some mechanism (discussed subsequently), and placed into the param store in encrypted form (ie. E_secret).

Once an authorised user has connected and obtained E_secret they launch the script as user3p using sudo. The script must only be available to user3p and it contains the means to decrypt E_secret that gets provided at runtime eg. via cli. Solutions here have varying degrees of suitability and integration with the aws environ.

Some of any number of options here: the aws-encryption-cli, gpg2 or openssl (already installed), r/age, or your whole script implemented in python3 and calling on eg. libsodium cryptobox via pysodium, or eg. cryptography.io, ... the goal here is to check the integrity of E_secret and decrypt to obtain SECRET_3p. (Feel free to ask a follow-up question...)

Once the script has derived SECRET_3p it places this into a new config file, then launches prog3p. Before any data are written into the new config file it must set strict permissions to avoid leaking. Once the 3rd-party program finishes, or possibly sooner, the config file is removed, meaning you would effectively be re-creating the config file at every launch.

Once the config file is written, the script should overwrite and then dispose of all variables that contain any secret material. (How you do this will depend on what you use to produce the script.) It should avoid placing any of these into the environ, or passing via the command-line, if at all possible.

Depending on how prog3p behaves, you might be able to place SECRET_3p into a temporary file, wait long enough for it to open a fd and read the contents into ram, and then remove (unlink) the recently created file Tomblin'09.

As far as I know, if prog3p still holds an open fd, the kernel will leave the bytes 'til after the fd is closed, but it wouldn't surprise me if there were caveat/s to this behaviour that I'm unaware of!) Eg. on a physical host you control this can work quite well in conjunction with eg. /dev/shm/, but I don't know how well it behaves within aws, so take it with a grain of salt...