Investigate about Helm deployment

[vcerenu]

The current method to deploy Wazuh in Kubernetes is with Kustomization. Investigating about the use of Helm for Kubernetes deployment is necessary.

[0dragosh]

Was looking to deploy this in the lab, a big platform that I lead at work to follow, and this is was a big show stopper.

Would love to have a simple helm chart that I could use with FluxCD.

[jeffreyflynt]

Maybe this would help get the ball rolling: https://github.com/arttor/helmify

[gecube]

@0dragosh Hi! I am completely happy with current setup as FluxCD perfectly supports kustomize approach.

[lucasfcnunes]

I really think having a Helm chart for Wazuh would be great... Here's what I think:

1. Simplified Deployment: Helm charts provide an efficient way to package, distribute, and manage Kubernetes applications. With a Helm chart, deploying Wazuh becomes straightforward, especially for users familiar with Helm.
2. Standardization: Helm charts establish a common framework for deploying applications. By adopting a Wazuh Helm chart, the community can ensure consistent deployments across different environments.
3. Integration with FluxCD: Helm charts seamlessly integrate with FluxCD, enabling automated deployments and continuous delivery. This integration streamlines updates and maintenance.
4. Community Adoption: Helm is widely adopted in the Kubernetes ecosystem. By creating an official Wazuh Helm chart, we encourage more users to explore and adopt Wazuh.
5. Ease of Customization: Helm values allow users to customize Wazuh deployments easily. Users can adjust configurations, secrets, and other parameters directly in the Helm chart.

Let's work together to make Wazuh even more accessible and user-friendly!

[gecube]

Hello!

@lucasfcnunes I strongly believe that all mentioned points are not true 100%. Let me argue.

1. Simplified - but helm introduces it's own complexity. So if you will use hooks, it creates a mess. And also it is really weird to dig through 1000 line values.yaml file.
2. Standardization - agree.
3. Integration with FluxCD - the FluxCD or even ArgoCD can consume just pure manifests with no issues. So I can point to remote repo and apply kustomization patches to fix some settings if necessary.
4. Community Adoption: - agree
5. Ease of Customization - unfortunately, Wazuh is stateful application. It means that typical k8s approaches like rolling deploy are not enough to maintain Wazuh well. For instance, how would you make management of secrets for wazuh? I proposed the change from bare sh-scripts (which would be naively used in Helm hooks) to cert-manager, but no success. I think the best option for Wazuh is writing the operator - like for many other stateful things (postgres - zalando operator, cn-pg, crunchy, kafka - strimzi, elastic - eck etc.). The operator could be installed by Helm (no doubts) and it will take care of Wazuh instance(s) maitenance and provice some nice configuration options. Even more - wazuh-agents for collecting data should be installed somehow and operator could be a good approach for it also!