Request: support for taints and tolerations to KubeArmor deployments in Helm charts.

[oxie]

We would like to request support for taints and tolerations to KubeArmor deployments in Helm charts.

Is your feature request related to a problem? Please describe the use case.

Currently, the KubeArmor deployments like kubearmor-relay, kubearmor-operator, and kubearmor-controller deployed via Helm charts do not support taints and tolerations. This limitation restricts the ability to deploy KubeArmor components on tainted nodes within Kubernetes clusters, particularly in environments with specialized node configurations or security requirements.

Describe the solution you'd like

We would like to request that the Helm charts for KubeArmor deployments to include options for specifying taints and tolerations. This feature would allow users to deploy KubeArmor components on specific nodes that have been tainted to restrict pod scheduling, thus enhancing the flexibility and security posture of Kubernetes clusters using KubeArmor.

Describe alternatives you've considered

As an alternative, users could manually edit the deployment YAML files generated by Helm to include taints and tolerations, but this approach is less maintainable and error-prone, especially during Helm chart upgrades or re-deployments. Integrating taints and tolerations directly into the Helm charts would provide a more robust, user-friendly, and maintainable solution.

[tico88612]

@daemon1024 Can I working on this? Thanks.

[daemon1024]

@tico88612
Thanks for the interest.

Just to provide some context.
It will involve two aspects.

1. Supporting this configuration in the KubeArmor Operator helmchart itself, so as to deploy Operator Deployment with appropriate taints and toleration
2. Individual taints/tolerations configuration for each of the deployments (except daemonset) in KubeArmor-Config CRD.

[tico88612]

Hi @daemon1024

I've added the toleration fields for helm/KubeArmor (controller & relay) and helm/KubeArmorOperator.

But I was thinking about the CRD part. Should I add KubeArmorRelayToleration and KubeArmorControllerToleration directly?

KubeArmor/pkg/KubeArmorOperator/api/operator.kubearmor.com/v1/kubearmorconfig_types.go

Lines 50 to 53 in ecdea89

	// +kubebuilder:validation:optional
	KubeArmorRelayImage ImageSpec `json:"kubearmorRelayImage,omitempty"`
	// +kubebuilder:validation:optional
	KubeArmorControllerImage ImageSpec `json:"kubearmorControllerImage,omitempty"`

Because it's different from other CRD designs (Prometheus Operator) that I'm referring to, I want to make sure it's feasible to go in this direction.

Prometheus Operator CRD (Alertmanager): https://github.com/prometheus-operator/prometheus-operator/blob/3e7eb79e25ac497fd44753261e23cbed9faa36f5/pkg/apis/monitoring/v1/alertmanager_types.go#L166-L167

[daemon1024]

@tico88612

I've added the toleration fields for helm/KubeArmor (controller & relay) and `helm/KubeArmorOperator

Nice.

But I was thinking about the CRD part. Should I add KubeArmorRelayToleration and KubeArmorControllerToleration directly?

KubeArmor/pkg/KubeArmorOperator/api/operator.kubearmor.com/v1/kubearmorconfig_types.go

Lines 50 to 53 in ecdea89

	// +kubebuilder:validation:optional
	KubeArmorRelayImage ImageSpec `json:"kubearmorRelayImage,omitempty"`
	// +kubebuilder:validation:optional
	KubeArmorControllerImage ImageSpec `json:"kubearmorControllerImage,omitempty"`

Yep this looks like the place to add, please reflect the changes where the operator deploys them as well. Thanks 🙌🏽
Appreciate you working on this and looking forward to the PR