feat: add support for "pinned" images

[inFocus7]

TODO (very likely) - move logic from the scanner to the collector & remover

What this PR does / why we need it:

Add support for CRI pinned images. Pinned is a field images which should not be garbage collected have. When scanning images for removal we should .

We also make this configurable to allow users to decide whether or not they care about pinned images.

Which issue(s) this PR fixes:
Fixes #380

Special notes for your reviewer:
The configurability can be removed if we think that images being pinned is enough for us to assume they should never be deleted.

---

Notes for me (Fabian) so I ensure these behaviors occur...

deletePinnedImages: true

	isPinned	notPinned
isVulnerable	delete	delete
notVulnerable	keep	keep

deletePinnedImages: false (default)

	isPinned	notPinned
isVulnerable	keep	delete
notVulnerable	keep	keep

• Do we care about scanning pinned images if deletePinnedImages: false? Since we'll be keeping them either way...
  • As of now, I don't believe we have any reporting of CVEs, so scanning images we know we won't delete won't help with anything, but could keep us open to add to reports if we do so in the future (surface vulnerable images #356). I'll look into how/if we do special case handling for deleteEOL and other similar flags.

[inFocus7]

will look into why this got removed, i did hit some issues when I last generated code due to not being able to covert unversioned...Pinned to <version>...Pinned as the Pinned field did/does not exist in versioned generations.

[inFocus7]

hit issues locally due to the infamous

unknown revision <kubernetes-library> v0.0.0

requiring me to pin this.

[inFocus7]

The util.IsExcluded function does a idToImageMap[imgDigestOrTag], although I would expect it to use the imageId as the key..

[pmengelbert]

The reason is a frustrating one: Docker's ImageID is different from Containerd's Digest. Newer versions of docker can use containerd to manage storage & metadata of images.

But without that feature, docker reports the sha256 digest of the Image Config as the ImageID. On the other hand, containerd's Image Digest is the sha256 digest of the image manifest. Of the two, the image digest is more stable, because the name of the image is included in the Image Config. Thus, a change to the name of an image (without any changes to the image itself) will result in a change to the ImageID.

Thus we use the digest as the hash key for the Set of images we build. Each distinct digest is a distinct image, full stop; the same is not true for ImageIDs: tag an existing image with a new name and you have one distinct image with two distinct ImageIDs.

The CRI is kind of in an in-between state. It was developed to provide an interface and had to work with older clusters using dockershim and newer clusters using containerd. As such, it takes the ImageID into account more than it should.

Using trivy to scan by ImageID doesn't work. Trivy scans the containerd image store by creating a containerd client (from the containerd library) and querying it directly. Since containerd doesn't manage images by docker's ImageID, it can't provide any image information to trivy for the scan if it's looking for it by ImageID.

We want to scan and remove by content as much as possible, not by name. We use the image name + tag as a backup in the event that the call to the CRI's ListImages returns an image with no digest information. This happens surprisingly frequently because of the ImageID cruft in the CRI implementation.

[pmengelbert]

Thank you so much for the draft PR, and apologies for taking so long to review. I've suggested some changes to the general approach, and I will be happy to clarify if anything isn't clear.

[pmengelbert]

You will want to make a simultaneous identical change to v1 and unversioned. We keep unversioned synchronized with the latest api version for each type. Currently:

• imagejob_types.go -> v1 == unversioned
• imagelist_types -> v1 == unversioned
• eraserconfig_type -> v1alpha3 == unversioned

[pmengelbert]

We are making an effort to stop using cli args to control the container applications. We are using the configmap instead. In the code that spawns this pod (imagecollector_controller.go or imagejob_controller.go), we can set an environment variable based on the configmap value.

For more information as to why we are moving away from cli args:
#446

[pmengelbert]

The reason is a frustrating one: Docker's ImageID is different from Containerd's Digest. Newer versions of docker can use containerd to manage storage & metadata of images.

But without that feature, docker reports the sha256 digest of the Image Config as the ImageID. On the other hand, containerd's Image Digest is the sha256 digest of the image manifest. Of the two, the image digest is more stable, because the name of the image is included in the Image Config. Thus, a change to the name of an image (without any changes to the image itself) will result in a change to the ImageID.

Thus we use the digest as the hash key for the Set of images we build. Each distinct digest is a distinct image, full stop; the same is not true for ImageIDs: tag an existing image with a new name and you have one distinct image with two distinct ImageIDs.

The CRI is kind of in an in-between state. It was developed to provide an interface and had to work with older clusters using dockershim and newer clusters using containerd. As such, it takes the ImageID into account more than it should.

Using trivy to scan by ImageID doesn't work. Trivy scans the containerd image store by creating a containerd client (from the containerd library) and querying it directly. Since containerd doesn't manage images by docker's ImageID, it can't provide any image information to trivy for the scan if it's looking for it by ImageID.

We want to scan and remove by content as much as possible, not by name. We use the image name + tag as a backup in the event that the call to the CRI's ListImages returns an image with no digest information. This happens surprisingly frequently because of the ImageID cruft in the CRI implementation.

[pmengelbert]

Instead of passing a boolean flag, just require that the caller remove any pinned images from targetimages before invoking this function. It won't require any changes here but will require them elsewhere.

If the collector is turned on, filter them out during the collector stage. If the collector (and therefore scanner) is turned off, filter them out just prior to removal.