feat(image): custom docker host option

[aswath-s-tw]

Description

This is a draft. Added custom docker socket option --docker-host. Please review and suggest changes.

Related issues

• Close custom docker socket for image scan option #2997

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[CLAassistant]

All committers have signed the CLA.

[AndreyLevchenko]

as for testing: there is probably nothing that can be tested in docker_test. However in image_test you can set custom DockerHost for test docker engine and then check if you can successfully reach it

[aswath-s-tw]

Hey @AndreyLevchenko , Thank you so much for suggesting changes. Have tried my bit in improving the code as per the mentioned suggestions. Please take a look at it and let me know ! Thanks again.

[aswath-s-tw]

Not sure why the windows section in pipeline failed. Any ideas on this ?

[aswath-s-tw]

I think i got it, for windows, the domain socket url starts with npipe instead of unix. not sure how we handle this though ! Any suggestions @AndreyLevchenko

[AndreyLevchenko]

I think i got it, for windows, the domain socket url starts with npipe instead of unix. not sure how we handle this though ! Any suggestions @AndreyLevchenko

There is lot of examples in trivy code. For instance https://github.com/aquasecurity/trivy/blob/main/pkg/misconf/scanner_test.go#L128

[aswath-s-tw]

@AndreyLevchenko, can you trigger the pipeline to see if the current change works ?

[pmengelbert]

There is already a way to set the socket address for containerd, and it's done by environment variable.

This PR splits the configuration of the socket: docker uses a cli arg and containerd uses an env var. What's more, the socket for the podman daemon can only be set indirectly by the XDG_RUNTIME_DIR env var.

It's a little awkward to have three different ways to configure the socket address for the three different supported runtimes. Would it be possible to expand the scope of this PR to include support for the other runtimes as well? You would probably also want to rename the flag from --docker-host to something like --runtime-host, since it would apply across runtime implementations.

[aswath-s-tw]

sure @pmengelbert , that makes total sense. I can maybe get into implementing your suggestion right after we figure out how to resolve the test for windows environment.

[knqyf263]

I feel like --runtime-host could be confusing. I think we want to configure the specific runtime explicitly. I prefer --docker-host for the reason. Or, we may need something like --runtime-host docker:/path/to/socket.

[aswath-s-tw]

@knqyf263 @pmengelbert I think we can limit the scope of this issue / PR to support --docker-host and discuss more about --runtime-host in a different issue ? Let me know your thoughts.

@AndreyLevchenko Also the pipeline is green RN. Please review and accept the PR or suggest changes if any.

Thanks !

[pmengelbert]

I feel like --runtime-host could be confusing. I think we want to configure the specific runtime explicitly. I prefer --docker-host for the reason. Or, we may need something like --runtime-host docker:/path/to/socket.

@knqyf263 Since the code looks for the image by first attempting the docker socket, then the containerd socket, then podman, then remote registry, I think you are right that there should be either a) separate flags or, b) --runtime-host can be supplied multiple times with the runtime as the scheme of the url. Separate flags is probably easier. Thoughts?

The other issue is, what happens if users supply both the flag and the env var? I assume the CLI arg takes precedence.

@knqyf263 @pmengelbert I think we can limit the scope of this issue / PR to support --docker-host and discuss more about --runtime-host in a different issue ? Let me know your thoughts.

I'll defer to @knqyf263 but IMO this PR should at least allow setting the socket address by environment variable, since users can do so already with containerd and podman. Thoughts?

[aswath-s-tw]

I guess all 3 container runtimes can be configured by ENV vars already. The scope of this issue was to add a flag to control the host for local docker engine scan.

[knqyf263]

Separate flags is probably easier. Thoughts?

trivy image --docker-host /path/to/docker.sock --containerd-host /path/to/containerd.sock

or

trivy image --runtime-hosts docker:/path/to/docker.sock --runtime-hosts containerd:/path/to/containerd.sock

The first one may be more intuitive.

The other issue is, what happens if users supply both the flag and the env var? I assume the CLI arg takes precedence.

Yes, CLI flags should take precedence. I believe WithHost takes care of that.

trivy/pkg/fanal/image/daemon/docker.go

Line 20 in c447d1c

opts = append(opts, client.WithHost(host))

I guess all 3 container runtimes can be configured by ENV vars already. The scope of this issue was to add a flag to control the host for local docker engine scan.

Right.

[aswath-s-tw]

So shall I start working on these changes ? I have one doubt though. Let's assume this scenario. If the user provides --containerd-host as an arg, should we limit the scan to just containerd and ignore the other 3 scanners ? Same question applies for other host options as well !

[pmengelbert]

Related #3049

[aswath-s-tw]

#3599 (comment)

Any updates on this comment ? I can work accordingly if we can make a decision !

[pmengelbert]

LGTM. I'm not a maintainer, but since I commented earlier requesting changes, I should note I am fine with this being merged as is (after a rebase).

@knqyf263 can the remaining work on the flags be accomplished in a separate PR? It's already being tracked by #3049

[knqyf263]

We recently refactored options, and it causes conflicts. It is just bothering you, so I've resolved them.

should we limit the scan to just containerd and ignore the other 3 scanners ?

No, I don't think so. --docker-host just configures the socket path.

[knqyf263]

Thanks for your patience!