The operator manages the lifecycle of the installNamespace (default falcon-system). When deploying from a custom registry that requires a pull secret, the user has to either:
Create the falcon-system namespace and the secret before creating the FalconNodeSensor
Create the FalconNodeSensor, wait for the operator to create the falcon-system namespace, then create the secret
This is not an ideal workflow. It would make more sense for the configuration of such secrets to be in the falcon-operator namespace and then copy those secrets to a managed secret in the installNamespace.
The operator manages the lifecycle of the installNamespace (default falcon-system). When deploying from a custom registry that requires a pull secret, the user has to either:
This is not an ideal workflow. It would make more sense for the configuration of such secrets to be in the falcon-operator namespace and then copy those secrets to a managed secret in the installNamespace.
Related, the docs are not clear on where the secret should reside ("(optional) list of references to secrets to use for pulling image from image_override location.") especially since the FalconNodeSensor is now cluster-secoped. However, the samples does mention falcon-system (although does not mention installNamespace): https://github.com/CrowdStrike/falcon-operator/blob/main/config/samples/falcon_v1alpha1_falconnodesensor-all-options.yaml#L29-L33