ArgoCD: autoDeploymentUpdate generate two MutatingWebhookConfiguration objects

[CarpathianUA]

Hello,

When autoDeploymentUpdate: true enabled and falcon-container-sensor is being synced via ArgoCD, two MutatingWebhookConfiguration are generated which prevents sync to be completed. Is it expected behavior? Is it related to Helm hooks? I would appreciate a more detailed description of For features that do not work in this instance, disable those features until ArgoCD supports Helm correctly from Deployment Considerations, point 5. What exactly those features?

chart version: 1.17.9
values.yaml:

        node:
          # When enabled, Helm chart deploys the Falcon Sensors to Kubernetes nodes
          enabled: false

        container:
          # When enabled, Helm chart deploys the Falcon Container Sensor to Pods through Webhooks
          enabled: true

          # Configure the number of replicas for the mutating webhook backend
          replicas: 3

          # Auto update the certificates every time there is an update
          # https://github.com/CrowdStrike/falcon-helm/tree/main/helm-charts/falcon-sensor#deployment-considerations-1
          autoCertificateUpdate: false

          # Update Webhook and roll out new Deployment on upgrade
          # https://github.com/CrowdStrike/falcon-helm/tree/main/helm-charts/falcon-sensor#deployment-considerations-1
          autoDeploymentUpdate: true

          # Disable injection for all Namespaces
          disableNSInjection: false

          # Disable injection for all Pods
          disablePodInjection: false

          # Certificate validity duration in number of days
          certExpiration: 3650

          # Configure the Injector Port
          injectorPort: 4433

          # Configure the requests and limits of the sensor
          sensorResources:
            limits:
              cpu: 300m
              memory: 256Mi
            requests:
              cpu: 10m
              memory: 20Mi

          # The key that is used to handle enabling/disabling sensor injection at the namespace level
          namespaceLabelKey: sensor.falcon-system.crowdstrike.com/injection

          image:
            repository: <REDACTED>
            pullPolicy: IfNotPresent
            # Set to true if connecting to a registry that requires authentication
            pullSecrets:
              enable: false
              # Configure the list of namespaces that should have access to pull the Falcon
              # sensor from a registry that requires authentication. This is a comma separated
              # list. For example:
              #
              # namespaces: ns1,ns2,ns3
              namespaces:

              # Attempt to create the Falcon sensor pull secret in all Namespaces
              # instead of using "container.image.pullSecrets.namespaces"
              allNamespaces: false

              # Value must be base64
              # The base64 encoded string of the docker config json for the pull secret can be
              # gotten through:
              # $ cat ~/.docker/config.json | base64 -
              registryConfigJSON:
            # Overrides the image tag whose default is the chart appVersion.
            tag: "<REDACTED>"

          resources:
            limits:
              cpu: 300m
              memory: 256Mi
            requests:
              cpu: 10m
              memory: 20Mi

        serviceAccount:
          name: crowdstrike-falcon-sa
          annotations: {}

        falcon:
          cid: <REDACTED>
          aid:
          apd:
          aph:
          app:
          trace: none
          feature:
          message_log:
          billing:
          tags: "<REDACTED>"
          provisioning_token:

[gaahrdner]

Does anyone have an answer to @CarpathianUA 's question? We're also using ArgoCd, so facing similar issues. We need to determine if this is just something we should roll out manually to clusters, try the falcon-operator, or re-evaluate Crowdstrike as a whole.

Preference would be to deploy this along with the rest of our tooling via Helm charts + ArgoCD. 🙇

[reza-koneksahealth]

Thumbs up to that!

[redhatrises]

The issue with ArgoCD is that they do not fully support helm and its capabilities, only helm template whereas FluxCD fully does support Helm. See https://argo-cd.readthedocs.io/en/stable/user-guide/helm/ and https://fluxcd.io/flux/use-cases/helm/ for what is and is not supported. There are native helm code/template functions that require a cluster to check against as well as hooks in the helm chart that helm template cannot process which means that ArgoCD cannot process either.

[CarpathianUA]

ArgoCD has partial support for Helm hooks https://argo-cd.readthedocs.io/en/stable/user-guide/helm/#helm-hooks
If needed hook(s) is supported - worth to add ArgoCD hooks-related annotations to the Helm templates of the chart.

[gaahrdner]

I reached out to Crowdstrike support however I don't think they are going to help out on this, rather they pointed me to this issue on ArgoCD. 😢

[sf-vorlov]

Similarly to the ArgoCD, the GCP Config Sync/Config Connector also templates the helm chart prior to deployment, which causes the following error:

two Cluster-scoped configurations with the same name and GroupKind: "MutatingWebhookConfiguration.admissionregistration.k8s.io" named "falcon-sensor-injector".

These two has same name:
source: .../crowdstrike/falcon-sensor/templates/container_deployment_webhook.yaml metadata.name: falcon-sensor-injector group: admissionregistration.k8s.io version: v1 kind: MutatingWebhookConfiguration

source: .../crowdstrike/falcon-sensor/templates/container_webhook_upgrade.yaml metadata.name: falcon-sensor-injector group: admissionregistration.k8s.io version: v1 kind: MutatingWebhookConfiguration

[redhatrises]

Release https://github.com/CrowdStrike/falcon-helm/releases/tag/falcon-sensor-1.27.1 no longer uses upgrade webhooks since the service should rollout changes on upgrade instead.