Control 0075 - Image pull policy on latest tag triggers randomly

[gnd]

Description

The C-0075 control treats all tags without numbers as latest. This is specified in the description of the control: https://hub.armosec.io/docs/c-0075:

Note as well that some vendors don't use the word latest in the tag. Some other word may also behave like the latest. For example, Redis uses redis:alpine to signify the latest. Therefore, this control treats any word that does not contain digits as the latest. 

Sometimes it happens that the hash function assigning tags at build (eg. $CI_COMMIT_SHORT_SHA) returns a hash without any numbers. This control then triggers a false positive. We would prefer if this check would only scan for lates tag and not do any magical assumptions about the nature of tag with or without numbers.

Environment

OS: Ubuntu 22.04 LTS
Version: built latest master

Steps To Reproduce

1. Deploy a deployment tagged with only letters such as befacaad which is an actual hash.
2. Scan with Kubescape

Expected behavior

Kubescape should not return this as a failed control.

Actual Behavior

Kubescape does return a failed control C-0075 for image tags which don't contain numbers. This can happen randomly. We can disable this control, but then we would loose the possibility to check for actual latest tags. It would be best if the "only letters" rule would be deactivated as it will trigger random false positives/

Additional context

[craigbox]

Thanks for the bug report @gnd; I've transferred it to the repo for the controls library.

[gnd]

Hello, any news on this ?

[alegrey91]

Hi @gnd, thanks for the bug report, and sorry for the late reply.
I just provided a fix for this rule so that you can scan it properly now.

[gnd]

Hello @alegrey91

thank you for the quick fix !

from what version of Kubescape can we expect this to be resolved ? We use latest master only to test some things, but run https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh to install it in prod

[alegrey91]

Hello @alegrey91

thank you for the quick fix !

from what version of Kubescape can we expect this to be resolved ? We use latest master only to test some things, but run https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh to install it in prod

Hi, I think I've been a bit hasty with this fix. I apologize for that.
We are basically allowing only latest tags to be considered as the latest.
Since other words may also behave like the latest, we should take this into account.
So, that said, let's see what does think other maintainers about this, and let's solve this issue.
cc @YiscahLevySilas1
Alternatively, is there a way to configure this control to avoid this behavior? Maybe we can solve the issue using the --controls-config flag in kubescape? @YiscahLevySilas1 WDYT?

[YiscahLevySilas1]

Hi @gnd Thanks for reporting this issue.
I understand the inconvienence of these false positives..
However, to check only latest tags as you suggested will lead to false negatives (like the redis example) which might be problematic. A solution we have in place is to "ignore" these failed images (either from the ARMO platform if you are using it, or by using the --exceptions flag), or to develop the ability to configure this control to use an allow list with the --controls-config flag like @alegrey91 suggested, but both of these would require approving each image separately. Would that be a solution that suits you?
@alegrey91 - Alternatively, maybe we could configure a boolean value (with the --controls-config like you suggested) that defines the behaviour of this control to one of the 2 ways mentioned, where the default behaviour is as it is today. WDYT?

[gnd]

Hi @YiscahLevySilas1 ,

thanks for looking into this.

Currently we can only disable the control for all namespaces. I think having it check for latest and sometimes triggering some specific images as false positives which then can be excepted is a much better approach.

I can only guess what the redis example is, since i dont see it here.

[alegrey91]

@alegrey91 - Alternatively, maybe we could configure a boolean value (with the --controls-config like you suggested) that defines the behaviour of this control to one of the 2 ways mentioned, where the default behaviour is as it is today. WDYT?

The best way to solve this issue is to allow the user to configure its own exceptions based on the images. Are we enabled to do this through the regolibrary framework?

[craigbox]

(Bug triage: not sure who that question was to Alessio. Was it to Yiscah?)

[XDRAGON2002]

Shouldn't it be possible to create a simple mapping as passed in the controls-inputs which a user could simply go ahead and modify to suit their exact image tags they are using? By default we would enable a bunch of commonly used latest tags and have the user make the choice as to what they want to disable?

This I believe would be a much cleaner method keeping in lieu with how some other cases have also been implemented.