You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered: