search

kubearmor / KubeArmor

Runtime Security Enforcement System. Workload hardening/sandboxing and implementing least-permissive policies made easy leveraging LSMs (BPF-LSM, AppArmor).
https://kubearmor.io/
Apache License 2.0
1.32k stars 325 forks source link

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

Open oxie opened 3 months ago

oxie commented 3 months ago

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 commented 2 months ago

@daemon1024 Can I working on this? Thanks.

daemon1024 commented 2 months ago

@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 commented 2 months ago

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?

https://github.com/kubearmor/KubeArmor/blob/ecdea89fa1f253bc80dc76c4a186c3d9c2dbdf91/pkg/KubeArmorOperator/api/operator.kubearmor.com/v1/kubearmorconfig_types.go#L50-L53

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 commented 2 months ago

@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?

https://github.com/kubearmor/KubeArmor/blob/ecdea89fa1f253bc80dc76c4a186c3d9c2dbdf91/pkg/KubeArmorOperator/api/operator.kubearmor.com/v1/kubearmorconfig_types.go#L50-L53

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