Prevent vulnerable images from running not working for initial image pull though a Proxy Cache project

[DASXCE]

Expected behavior and actual behavior: After creating a Proxy Cache project to DockerHub and configuring 'Prevent vulnerable images from running' the first image pull works even though the image has vulnerabilites. After a while(which may be related to #12721 ) subsequent pulls fail with a proper message 'cannot be pulled due to configured policy'. Expected was that the image will first be pulled into Harbor, scanned and then served to client running the pull command.

Steps to reproduce the problem:

1. Create a Proxy Cache project for DockerHub
2. Activate 'Prevent vulnerable images from running.' and set 'Prevent images with vulnerability severity of' to 'Low'
3. Activate 'Automatically scan images on push'
4. docker pull <<harbor_hostname>>/project_name/library/mysql:5

Versions: Please specify the versions of following systems.

• harbor version: 2.1.0
• docker engine version: 19.03.11-ol
• docker-compose version: 1.25.5

Additional context:

N/A

[reasonerjt]

@DASXCE This is the design of proxy cache, when you use pull through cache you expect the data be served before it's in the storage of Harbor, in that case Harbor will not be able to scan the image with the incomplete image data.

If you want to make sure the image is scanned, you need to use pull-based replication.

[xaleeks]

@a-mccarthy not sure if this is worth highlighting in the docs, your call.

[bmnave]

@a-mccarthy not sure if this is worth highlighting in the docs, your call.

Please add this to the docs as it is non-obvious and is still an issue in v2.2.0.

Understand that this use case is slightly outside of the proxy cache use case, but +1 for a feature to enable scan prior to serving the image. I would be okay with initial image pull failing with an error that says something like "image pending vulnerability scan. try back in XX seconds"

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bmnave]

+1

[geowalrus4gh]

+1

[haiwu]

+1

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[sathieu]

not stale

[jsolbrig]

I sincerely hope that something can be done to solve this issue. If it can't be solved, something needs to be added, prominently, to the documentation, describing methods for mitigation. Examples would be setting up admission controllers that do the actual vulnerability management.

Without either a fix or a conspicuously placed mitigation strategy, Harbor is a security threat just waiting to bite the unaware.

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[sathieu]

(Still) not stale

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[sathieu]

(still) not stale. Could it be marked as never-stale?

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[sathieu]

not-stale :disappointed:

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[sathieu]

not yet ...

[AYDEV-FR]

+1