Open Arabus opened 2 years ago
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).
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
What steps did you take and what happened:
What did you expect to happen:
Anything else you would like to add:
Environment:
Starboard version (use
starboard version
):0.14.0
Kubernetes version (use
kubectl version
):OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc):