You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 20, 2023. It is now read-only.
if i got you right the possible attack vector here would be somebody who uses malicious software (maybe in one of the dependent libs like some java package in teku etc.) to scan the container from inside for secret values, correct? I guess if a user losts the whole docker-host to an attacker he has even bigger problems than that ;-)
In any case the volume/file based aproach is far better than passing anything pe envvar as envvars can even be seen in /prod oder via docker-inspect without having some runtime components like apparmor or aqua (which both are more targeted for enterprise class orchestrators like nomad, kubernetes or swarm). I guess we dont have a chance to convince all the client-providers to support encryption in their files, so we need something which is transparent for the application i guess. Which on the other hand means that we will have to have something like a wrapper script which does decoding of an encoded file mounted as a volume and ensures that this file will be only readeable unencrypted by the application. Or fetching the contents from vault etc. Passing it over to the application could possibly work by writing the unencrypted value in a temporary file which is deleted as soon as the application read it and came up. But this scenario would only work if all the clients read their configuration only at startup :-(
Current plan is the following: each of our containers gets a little wrapper-program injected (preferably go) which fetches the secret files from vault, stores them on a in-memory/tempfs volume and starts the application. After ensuring that the application runs stable it deletes the file. Initial idea was that this could be done by an extra container (something like the init-containers in k8s) but i think thats the more straight forward aproach AND we can keep it even separated by client.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Evaulate:
The text was updated successfully, but these errors were encountered: