You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pods should be blocked to start on newly provisioned nodes until KubeArmor daemonset is fully running on that node.
Is your feature request related to a problem? Please describe the use case.
When Kubernetes cluster is automatically provisioning new nodes (via Cluster Autoscaler or Karpenter) for pods which are matching some of the KubeArmor policies, those pods scheduled to run on a newly created node might start actually sooner(!) than KubeArmor daemonset is fully working. On such a dynamically created clusters like this, it's just impossible to ensure the policies are always fully effective.
IMHO similarly as with networking, starting of pods which require a specific feature (security restrictions in this case) should be delayed until the feature is available.
Feature Request
Short Description
Pods should be blocked to start on newly provisioned nodes until KubeArmor daemonset is fully running on that node.
Is your feature request related to a problem? Please describe the use case.
When Kubernetes cluster is automatically provisioning new nodes (via Cluster Autoscaler or Karpenter) for pods which are matching some of the KubeArmor policies, those pods scheduled to run on a newly created node might start actually sooner(!) than KubeArmor daemonset is fully working. On such a dynamically created clusters like this, it's just impossible to ensure the policies are always fully effective.
IMHO similarly as with networking, starting of pods which require a specific feature (security restrictions in this case) should be delayed until the feature is available.
Describe the solution you'd like
I would follow the approach of Cilium (https://karpenter.sh/v1.0/concepts/nodepools/#cilium-startup-taint):
kubearmor.io/agent-not-ready=true
)The text was updated successfully, but these errors were encountered: