vulnerabilityScannerScanOnlyCurrentRevisions does not delete old reports

[Bernd May]

What steps did you take and what happened:

• Enable vulnerabilityScannerScanOnlyCurrentRevisions on starboard operator
• See reports generated only for most current deployments
• Deploy new revision of deployment
• See report generated for new deployment
• See old report is still there

What did you expect to happen:

• old report being deleted as I only want reports for the current deployments

Anything else you would like to add:

• The implementation in #870 simply didn't add that part of the feature

Environment:

• Starboard version (use starboard version): 0.14.0
• Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.2", GitCommit:"9d142434e3af351a628bffee3939e64c681afa4d", GitTreeState:"clean", BuildDate:"2022-01-19T17:27:51Z", GoVersion:"go1.17.6", Compiler:"gc", Platform:"darwin/arm64"}
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.3", GitCommit:"ca643a4d1f7bfe34773c74f79527be4afd95bf39", GitTreeState:"clean", BuildDate:"2021-07-15T20:59:07Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}

• OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc):

> sw_vers
ProductName:    macOS
ProductVersion: 11.6.2
BuildVersion:   20G314

[Julien Lamandé]

Hi @Arabus
it looks like an old issue ;-) Anyway the behavior didn't change yet.

Note that this behavior is related to the revisionHistoryLimit of a Deployment (default value of revisionHistoryLimit being currently 10).
If one changes revisionHistoryLimit to 0, only one replicaset of the deployment will be kept and so only one report too.

You can observe this with kubectl tree deploy my-deployment-name (using the kubectl tree plugin) where you can see the history replica sets on the deployment and even vulnerability or config reports.

Note that history of replicaset has some purpose as being able to rollback to a previous deployment (not sure of it to be necessary when using helm charts and helm rollback feature).

[Bernd May]

Hey @jlamande , thanks for the albeit late reply, I am aware of the workaround setting the deployment history. Unfortunately this comes at the price of being unable to rollback deployments. Imo getting the above feature should not be dependent on breaking another.

The reason I would want this feature is mainly a statistics issue - When supplying vulnerability dashboards to our engineers for their deployments I want them to be able to see data about their current deployment without past deployment data cluttering it. The metrics exporter unfortunately reports all of the vulns of all versions of a deployment.

I must admit though that we have since moved on to neuvector as it supplies all of the features of starboard and more without hassles like this. I am therefore no longer following this issue (and you might want to close it unless you see merit in it).

SN: helm rollback works differently, by reapplying the threeway diff of current deployment,cluster state and old state