aquasecurity / starboard

Discussed in #777

^{Originally posted by vincent-pli October 27, 2021}
I try to install startboard operator with the same OPERATOR_NAMESPACE and OPERATOR_TARGET_NAMESPACES, the operator scan itself and generate the report CRD, could we enhance it to ignore itself when in such scenario.

I found we have such mechanism to avoid scan operator itself but broken,

starboard/pkg/operator/controller/configauditreport.go

Lines 82 to 88 in 204d5df

    
           err = ctrl.NewControllerManagedBy(mgr). 
        
           	For(resource.forObject, builder.WithPredicates( 
        
           		Not(ManagedByStarboardOperator), 
        
           		Not(IsLeaderElectionResource), 
        
           		Not(IsBeingTerminated), 
        
           		installModePredicate, 
        
           	)).

Fundamentally Starboard operator is like any other K8s workload, i.e. it can be vulnerable and misconfigured. What is the real problem that you're trying to solve with this PR?

I have a ns named foo and I installed startboard operator to that ns and let it also to monitor ns: foo.

By my test, the startboard operator will scan itself(since starboard operator is also a pod), I think it's not the case, startboard operator should ignore itself, that's what I want to resolve in this pr.

I checked the code, we already has such mechanism, see the code snippet, just add the missing label: app.kubernetes.io/managed-by: starboard for the deployment of startbaord operator could resolve it.

am i missing something? @danielpacak

Well, your understanding is correct. My point is that you should scan the operator itself on a regular basis like any other pod.

In other words, the mechanism of preconditions and labels is there to exclude scan jobs from being scanned. Not necessarily to exclude the operator's deployment.

ok, so from the point of view of startboard oeprator, it suggest to scan the operator itself in such scenario and the specific label is for jobs, right?
if it's by design, please feel free to close the pr, thanks

ok, so from the point of view of startboard oeprator, it suggest to scan the operator itself in such scenario and the specific label is for jobs, right?
if it's by design, please feel free to close the pr, thanks

That's right. For your use case you may be interested in the general discussion where we described a need to exclude workloads from scanning based on different criteria #670

However, until we put this exclusion mechanism in place I'd suggest scanning Starboard Operator by default. Mainly because it runs with a service account that has extensive permissions.

	err = ctrl.NewControllerManagedBy(mgr).
	For(resource.forObject, builder.WithPredicates(
	Not(ManagedByStarboardOperator),
	Not(IsLeaderElectionResource),
	Not(IsBeingTerminated),
	installModePredicate,
	)).

Could the operator ignore itself when "OPERATOR_NAMESPACE" and "OPERATOR_TARGET_NAMESPACES" is the same one

Discussed in #777