Bug 1329056
| Summary: | [RFE] Support scanning a remote container image | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Alex Jia <ajia> |
| Component: | atomic | Assignee: | Brent Baude <bbaude> |
| Status: | CLOSED EOL | QA Contact: | atomic-bugs <atomic-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.4 | CC: | amurdaca, dornelas, dwalsh, miabbott |
| Target Milestone: | rc | Keywords: | Extras, FutureFeature, Security |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Release Note | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-03-02 23:09:15 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Alex Jia
2016-04-21 04:07:28 UTC
Since this is scanning a rootfs, we can not scan remotely currently. But once we explode content onto a registry then you would be able to mount and scan the image. We could also pull the image without installing it via atomic command. (In reply to Alex Jia from comment #0) > we have a similar application instance for atomic info --remote The `info` command only needs to get a metadata file from the registry. A scan requires that the entire contents of the image are available to the machine running the scan. Whether that's by pulling it or by making it available on a shared storage medium, the only way to scan a remote resource is by first making it a local one. (In reply to Daniel Walsh from comment #2) > Since this is scanning a rootfs, we can not scan remotely currently. But > once we explode content onto a registry then you would be able to mount and > scan the image. We could also pull the image without installing it via > atomic command. Even if we just download the tar, we will have to explode it first to scan it. I'm not sure there's a meaningful difference between pulling the image and exploding it onto the Docker graphdriver vs. pulling the image and exploding it somewhere else. Somehow we have to be able to mount the rootfs into the scanning container. Long-term, we'd like the atomic registry to be able to scan containers at configurable intervals (or whenever the registry admin prefers), so we could have tooling in the atomic command to query scan results, but we won't be able to do this for images hosted on Docker Hub, likely ever. Can we make this _remote_ scanning a feature of our RH registry (or Atomic Registry perhaps) so that we also have a nice UI with Cockpit to show scanning results? Then, probably provide an API directly so atomic tool can consume to provide scanning results. Does this make any sense? (In reply to Antonio Murdaca from comment #4) > Can we make this _remote_ scanning a feature of our RH registry (or Atomic > Registry perhaps) so that we also have a nice UI with Cockpit to show > scanning results? Then, probably provide an API directly so atomic tool can > consume to provide scanning results. Does this make any sense? I was just thinking about this. We could have an API extension for the atomic registry that would allow users with appropriate privileges to trigger scans. We could also scan images on docker.io by using the atomic registry as a proxy, pulling them to the atomic registry first and scanning them there. Sure but it would be nice to some how which image was scanned by which version of the scanning container. So I don't need to scan an image if it was already scanned at the registry by the same scanning container. |