Way to constrain only specific selectors

[alexeysofin]

Is there a way to constrain only apps with specific selector?

Right now kubearmor seems to add apparmor annotations to all pods, and the most granular constraint visibility is a namespace.

Current approach can be dangerous sometimes, e.g. when some policies don't make it to the nodes and system pods can't start.

[daemon1024]

@alexeysofin this maks sense. We need a way to limit what we annotate incase AppArmor is used an enforcer. I have added it to our Roadmap.

One way to avoid this could be, Can you switch to BPFLSM as an enforcer. Based on info at #1728. I see you are using Debian and has latest enough kernel.

We have documentation to enable BPFLSM at https://github.com/kubearmor/KubeArmor/blob/main/getting-started/FAQ.md#checking-if-bpf-lsm-is-supported-in-the-kernel

Or if you would approach a automated approach

kubectl apply -f https://raw.githubusercontent.com/kubearmor/KubeArmor/main/deployments/controller/updaterscript.yaml

Warning: After running the above script the nodes will restart.

The advantage with BPF LSM is that we have control over how we implement policies in the kernel and are not dependent on a different engine to help us enforce it. As well as we enforce policies only on Pods where the policy is applied since we don't need to keep track of intermediary apparmor profiles and annotation lifecycle.

Let me know What do you think? Happy to help out further in this thread to help succeed your usecase with KubeArmor. Or we can have more synchronous discussion over our Slack - Invite

[alexeysofin]

Thank you for the advice @daemon1024, I'll try switching to bpf enforcer, although bpf is still a pretty early technology.

By the way maybe you help with clarifying #1728 as well? Is this only apparmor's enforcer peculiarity or that's the approach kubearmor is taking for all enforcers?

[daemon1024]

Thank you for the advice @daemon1024, I'll try switching to bpf enforcer, although bpf is still a pretty early technology.

Just for some clarification we are not using bpf for enforcing like tetragon does. We are using BPF LSM. These are meant for security enforcement and integrate with the LSM APIs exactly like AppArmor or SELinux, just that we have the flexibility to plugin our programmable logic. Specifically for the io uring example I don't have an answer, I will simulate it on my end, but we can ascertain that if it would fail in case of BPFLSM most likely it's going to fail with AppArmor as an enforcer as well.

By the way maybe you help with clarifying #1728 as well? Is this only apparmor's enforcer peculiarity or that's the approach kubearmor is taking for all enforcers?

It's an apparmor enforcer peculiarity. (Some of the things that we have documented in this context https://github.com/kubearmor/KubeArmor/wiki/Enforcer-Feature-Parity)

I am setting up an env and trying it out so I can better respond, because it's not clear to me why would the same apparmor profile have different behaviours when KubeArmor attaches it and you do it manually.

[alexeysofin]

Good to know that, thanks a lot

because it's not clear to me why would the same apparmor profile have different behaviours when KubeArmor attaches it

yes, that's the most interesting part

[alexeysofin]

@daemon1024 did you manage to reproduce this one?