container image scan annotation should always write

[aweiteka]

When this code[1] annotates an image, it should annotate the boolean every time, true or false, not just when true. This enables other tools to know if the scan has passed through policy while providing the same functionality. This would also require an update to the default policy since the action only is triggered on "high" or "critical" result.

cc @enoodle @simon3z

[1]

manageiq/app/models/container_image.rb

Line 96 in 6f8106a

"images.openshift.io/deny-execution" => "true"

[simon3z]

@miq-bot assign enoodle

[simon3z]

Let's review and comply with: openshift/openshift-docs#4206

cc @aweiteka @enoodle @pweil-

[aweiteka]

Let's review and comply with: openshift/openshift-docs#4206

Good point. It is a bit dangerous to assume "ownership" of the deny-execution annotation since it's not namespaced. The proposed annotation will solve this issue much more generally.

[moolitayer]

I'm trying to understand if there are situations where an image that had a compliance problem will become compliant again. Surely when we have the hash of the image it can not become compliant again?

container_image.full_name
 => "docker.io/openshift/origin-docker-registry@sha256:4b9f2be87f444d2a5edda635cee6791f33bf97d59604307a827ebd0d49a9cde9" 

I'm not sure, are there still cases when we pull the image by name alone?
(cc @enoodle )

[aweiteka]

I'm trying to understand if there are situations where an image that had a compliance problem will become compliant again.

Right. Once it's not compliant we don't expect it to become compliant again. However, there may be different tools external to OpenShift that have different thresholds or criteria (aka policy) for compliance, thus my namespace comment.

[aweiteka]

Let's review and comply with: openshift/openshift-docs#4206

PR merged. New issue to track this: #15212

[cben]

I'm trying to understand if there are situations where an image that had a compliance problem will become compliant again. Surely when we have the hash of the image it can not become compliant again?

1. I'd imagine that sometimes a buggy/overbroad vulnerability definition can be relaxed / made more specific?
   And certainly the opposite is possible — a compliant image might become non-compliant with newer definitions.

2. Whether ManageIQ sets allow/deny depends not only on scan results but also on ManageIQ policies.
   E.g. if I have policy annotating "deny" on Medium+ openscap severity, then I change it to deny on High only, allow otherwise, some images will change deny->allow.

@moolitayer @enoodle IMO when setting deny-execution we better clear allow-execution and vice versa.

[moolitayer]

I'd imagine that sometimes a buggy/overbroad vulnerability definition can be relaxed / made more specific?
And certainly the opposite is possible — a compliant image might become non-compliant with newer definitions.

I found this answer:
#15013 (comment)

I think it is to safest to assume both (also due to your second bullet)

@moolitayer @enoodle IMO when setting deny-execution we better clear allow-execution and vice versa.

I see the discussion on this one moved to the PR