Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'secret key' used for encrypting credentials lost on recreating image #16

Closed
sjwk opened this issue May 5, 2020 · 2 comments
Closed

Comments

@sjwk
Copy link

sjwk commented May 5, 2020

I'm running the container on Docker CE 19.03.8 via docker-compose, on a Ubuntu 18.04 server.
Having got it running and run some scans, all works fine. And I think stopping/starting/restarting the container is fine.
But if I use docker-compose down/up to recreate the image I can't start scan tasks afterwards. They move to 'requested' state, but never start and can't be cancelled. Looking in the logs, I see (for instance):

==> /usr/local/var/log/gvm/gvmd.log <==
event task:MESSAGE:2020-05-05 09h37.39 UTC:603: Status of task Scan domain controllers (79d3fa36-c325-4c4e-97c9-0045373da405) has changed to Requested
event task:MESSAGE:2020-05-05 09h37.39 UTC:603: Task Scan domain controllers (79d3fa36-c325-4c4e-97c9-0045373da405) has been requested to start by admin
util gpgme:WARNING:2020-05-05 09h37.39 UTC:606: error decrypting credential: No secret key
util gpgme: INFO:2020-05-05 09h37.39 UTC:606: encrypted to keyid B8174B146B24, algo=1: No secret key

If I restart the container (to stop the stalled task) and then go back through and replace the passwords in all of the stored credentials (which generates similar warnings as above and then succeeds) then the task will start.

Presumably re-creating the image has lost an encryption key used to secure the credentials which is stored outside the /data location? Is there a way to preserve this through upgrades/recreating the image? Or have I missed a step or a setting when creating my docker-compose file;

version: "3.5"
services:
gvm:
container_name: gvm
image: securecompliance/gvm
restart: always
env_file:
- ./gvm.env
ports:
- "8080:9392"
volumes:
- ./storage/data:/data

@sjwk
Copy link
Author

sjwk commented May 5, 2020

Doing some more digging, I believe the files concerned are located in /usr/local/var/lib/gvm/gvmd/gnupg - so obviously one option is to mount a volume there to ensure those files are persistent, or to have the Dockerfile create a link there pointing into /data so as to minimise the number of volumes. But I don't know whether there is a better option, or if doing so would increase a security risk of having these files accessible on the host system? (Although untrusted users probably shouldn't have shell access to the server running security scans, containerised or not!)

@pixelsquared
Copy link
Member

pixelsquared commented May 5, 2020

I think adding a symlink from /usr/local/var/lib/gvm/gvmd/gnupg to /data would be the best solution. I don't think it is really a security risk because the files are on the host system either way just in different places.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants