-
Task
-
Resolution: Done
-
Normal
-
None
-
None
-
None
-
None
Overview:
For the epic to make Scanner V4 the default for workload CVE scanning, we had to introduce defaulting logic in our operator. Due to the criticality of the project we decided to to focus on a solution which is built on a general concept but whose implementation is currently pretty much tied to the use-case of having a single defaulting flow, specifically for Scanner V4.
Because of the following short-comings we need to iterate on the current solution:
1. The reconciler flow is currently working on an instance of the central CR object. As part of our new defaulting flow we are mutating this object's spec. There is the danger that this mutated spec gets applied to the cluster, which must not happen, because its content should be in exclusive control of the user. We have checked that currently the only reconciler flow which could apply the spec to the cluster is when the CR gets deleted. Therefore we are currently checking within our spec-mutating extension if a deletionTimestamp is set or not and if it is we terminate without doing anything. Even though this approach works for now it is fragile and would require extra-care when we bump the helm-operator dependency.
2. The current approach implementation is tied to the requirements of Scanner V4 and we cannot easily add a second extension (per reconciler) implementing another defaulting flow. Reason being that if we would just clone the extension, the second extension would interfere with the spec-mutating of the first one: After the first one has run, the in-memory central object would carry the modifications for the defaulting but those would not be persisted on the cluster. When the second extension runs it would patch the object's annotations and as part of that the resulting object on the cluster would be fetched and the modifications from the first extension would effectively be overwritten.
So we need to think again about the lifecycle of our defaulting changes to the spec, maybe it would be feasible to keep them separate from the object, which traverses the reconciliation flow. After all, we solely need these changes for the value translator.