Add ttlSecondsAfterFinished to the vulnerabilityreports Job.

[yuzujoe]

After the job created by vulnerabilityreports is finished, the job itself is still there, although the pod is finished.

kubectl get job -n starboard-operator 
NAME                                  COMPLETIONS   DURATION   AGE
scan-vulnerabilityreport-549c778ff    1/1           27s        4d19h
scan-vulnerabilityreport-55984d8df5   1/1           71s        4d20h
scan-vulnerabilityreport-59f6d7b965   1/1           31s        4d22h
scan-vulnerabilityreport-6667f5b4c9   1/1           31s        4d22h
scan-vulnerabilityreport-6775b75db    1/1           30s        4d22h
scan-vulnerabilityreport-69bcd4b5cc   1/1           33s        4d20h
scan-vulnerabilityreport-6fcbd47599   1/1           37s        4d22h
scan-vulnerabilityreport-7fc87b9894   1/1           60s        4d16h
scan-vulnerabilityreport-85f8585769   1/1           27s        4d20h
scan-vulnerabilityreport-bf89796c6    1/1           32s        4d20h

This seems to me to prevent the job from starting even when the image is replaced or a new pod is created.
I think the reason for this is that I haven't added .spec.ttlSecondsAfterFinished, which will allow me to delete the Job after a specified time.

https://github.com/aquasecurity/starboard/blob/main/pkg/vulnerabilityreport/scanner.go#L144

Thanks.

[danielpacak]

👋 @yuzujoe Adding TTL param to the scan job spec is a great idea as a fallback. However, IIRC this in a beta feature (TTL Controller) and is not enabled by default in all clusters / cluster versions. Therefore, Starboard Operator is managing the whole lifecycle of scan jobs in reconciliation loops that it implements. In case the underlying K8s workload is deleted while scan job is still pending we should delete the job anyway. I'll double check whether we handle such scenario in code.

Meanwhile, could you share any logs of the operator that may help identifying why those jobs where not automatically deleted? Sharing minimal reproduction steps would be very helpful as well.