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
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;
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!)
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.
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):
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;
The text was updated successfully, but these errors were encountered: