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
It would be cool if we were able to create a docker provider (not just for testing) which can discovery running container assets and images, as well as snapshot the running containers them through docker save and scan both the snapshots and images.
Proposed Solution
A new provider like the other cloud providers, which talks to the docker daemon to get a list of running containers and container images. These are reported as assets to the control plane. When an asset is chosen to be scanned the provider will receive the asset, determine if it is a runtime container or an image, then follow this flow:
If the asset is a runtime container:
A snapshot will be taken through docker commit saving the containers file system to a new container image
Then:
A scanner container will be booted with the docker socket mounted, and then the container image (either the original or the runtime snapshot) is configured as the input to the VMClarity CLI as a local container image.
Alternatives Considered
None
Additional Context
This can also be used as a good candidate for e2e testing because it should not require anything more than a machine running docker.
The text was updated successfully, but these errors were encountered:
Problem Statement
It would be cool if we were able to create a docker provider (not just for testing) which can discovery running container assets and images, as well as snapshot the running containers them through docker save and scan both the snapshots and images.
Proposed Solution
A new provider like the other cloud providers, which talks to the docker daemon to get a list of running containers and container images. These are reported as assets to the control plane. When an asset is chosen to be scanned the provider will receive the asset, determine if it is a runtime container or an image, then follow this flow:
If the asset is a runtime container:
docker commit
saving the containers file system to a new container imageThen:
Alternatives Considered
None
Additional Context
This can also be used as a good candidate for e2e testing because it should not require anything more than a machine running docker.
The text was updated successfully, but these errors were encountered: