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...
- auth'd user connects to ec2 host via
- user obtains encrypted static secret
E_secret from the param store/ equiv.
- user launches a script as eg.
- script decrypts
E_secret using some mechanism that it holds to obtain
SECRET_3p, then destroys
- script re-creates config file as securely as possible, destroys
SECRET_3p, then launches 3rd-party program
prog3p runs under
user3p and does its thing
- 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.
Once an authorised user has connected and obtained
E_secret they launch the script as
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
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...