Setup: I have an application that I currently deploy manually on a server. It requires several credentials (client secrets of external services, tokens, and AES keys and IVs etc.) that I currently have stored in a file encrypted with
gpg. Whenever I restart the application I unlock the
gpg-key in the console and the service will then decrypt the file again from within the application script (as
gpg-agent persists the passphrase in memory for a limited time) and parse them through a pipe.
The advantage of this method is that neither the credentials nor the
gpg-passphrase needed to access them are NEVER persisted to disk and only kept in memory. So even with full root access it is impossible to recover the credentials. The only chance is to gain access during the short time-window during which the
gpg-key stays unlocked.
The disadvantages are that (a) no other user can start the service (unless we share my account) and (b) the application cannot be started by any automated means.
There is the creds project on github that is similar to what I'm doing, but which still shares the above shortcomings. It may be possible to encrypt the file with multiple
gpg keys and then attempt to decrypt it with all keys until one succeeds.
Question: What are better ways to handle the credentials that is (a) accessible by multiple users without key or account sharing, (b) accessible by a CI/CD system (where I do not have a console every time a deployment happens), and (c) only keeps password data in memory? The "workaround" with multiple
gpg keys looks like a complex hack and doesn't work with CI/CD systems.