[operator] unknown workload kind: Node - outdated CRDs perhaps?

[consideRatio]

I ran operator 0.6.0 with trivy 0.12.0 a cluster wide, and ended up with two jobs that were created, with an associated scanner pod that successfully created a vulnerability report, but ended up with the following error related to an "unknown workload kind".

{"level":"error","ts":1602857243.560325,"logger":"controller","msg":"Reconciler error","reconcilerGroup":"batch","reconcilerKind":"Job","controller":"job","name":"e3e145fe-0f97-40c1-b964-7043ae4c578f","namespace":"starboard-operator","error":"writing vulnerability reports: unknown workload kind: Node","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/home/runner/go/pkg/mod/github.com/go-logr/[email protected]/zapr.go:128\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:246\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:218\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).worker\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:197\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1\n\t/home/runner/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:155\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil\n\t/home/runner/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:156\nk8s.io/apimachinery/pkg/util/wait.JitterUntil\n\t/home/runner/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:133\nk8s.io/apimachinery/pkg/util/wait.Until\n\t/home/runner/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:90"}

Oh, is this because the Vuln CRD needs to be updated, which is only updated on startboard init, separately from the provided resources in deploy/kubectl etc?

Here is the vulnerabilityreport according to the logs of the trivy scanner pod: https://pastebin.com/Tea9c0UR

[danielpacak]

I've seen that as well and I believe it's related to pod ownership. Some pods in the kube-system namespace are owned by the Node on which they run. However, the code for setting the owner reference did not expect the Node kind, only ReplicaSet, ReplicationController, Job, etc.

To fix that we have to:

• Revisit the logic just before we save the VulnerabilityReport objects
• Probably add permission for get, list, watch Nodes

FYI For each scan Job we add labels that identify the owner. To confirm that you can run:

$ kubectl get jobs -n operators --show-labels

[consideRatio]

Thank you @danielpacak that debugging trick was very useful to know about!

Do you know if it is possible to convert a GitHub discussion to an GitHub issue?

[danielpacak]

I know you can do the other way around. @lizrice do you know if we can convert this discussion to an issue?

[lizrice]

Unfortunately, it's not possible

[danielpacak]

I going to mark this one as answered because we have dedicate issue to solve this issue #234