Open juhosyrjanen opened 1 week ago
Hmm this is specifically when deploying with ArgoCD I'm guessing? Can you tell me what issues you're getting?
Hi, thanks for the quick reply!
By default, as these defaults are in place, the resources provisioned by the Helm chart are not able to schedule on AWS EKS based clusters. This can be overridden with the values.daemonset.tolerations
config as shown above.
This is essentially a minor bug fix, a user experience improvement as EKS/AKS etc users will have to override these defaults to use the chart.
I suggest removing these defaults, or adding a values.cloudProvider
config option that either disables or enables these as needed.
This is not related to ArgoCD.
How are you installing the sensor? Using a helm chart? I've never had issues when doing "helm install" and this is the first customer complaint I've seen.
We aim to be as automatic as possible, so we don't want to configure per cloud provider. Note that you can always override the tolerations directly in your install cmdline: --set daemonset.tolerations=....
Are you installing via the unified helm chart (https://github.com/wiz-sec/charts/tree/master/wiz-kubernetes-integration) or the sensor helm chart (https://github.com/wiz-sec/charts/tree/master/wiz-sensor)
Hello,
By default the Helm chart adds GKE specific tolerations to Wiz Sensor DaemonSet. This causes issues with EKS based deployments. The following values fix needs to be added in order to have Wiz correctly deploy on EKS.
ArgoCD diff shows the change as follows:
This default makes using the Helm chart in multi-cloud deployments a bit cumbersome.