Node Daemonset

[ReillyTevera]

Hello, just found this project and it looks like something that could solve a problem of ours (that being that we want to be able to develop apparmor profiles alongside our applications and have them be updated when we upgrade our app). That said I have a few questions before I start taking a deeper look into it:

• Is this still in the experimental or POC stage? IE, if we start using it is there a good chance that it will continue to be developed and maintained?
• Let's say that I patch an Apparmor CRD in place (like as part of my deployments). Is there a mechanism for something to automatically detect that that profile has been updated and then sync it to the hosts? I assume this would take the form of a daemonset that runs on each node that automatically reloads on-demand.

[Kaizhe]

@ReillyTevera sorry for replying you late. After thinking of the use case carefully, here is my response in the sysdig slack channel:

you can use the daemonset approach, but it requires a lot of sensitive mounts on your file system like the apparmor-loader. And from my expectation or my understanding to the use case, AppArmor should be provisioned long with your workloads (Infrastructure as Code) and you don’t expect to update your AppArmor profile in your production directly or a few times a day. So I don’t think there is a need to make a controller watch and update AppArmor profiles constantly

I would love to hear your use case and see how we can keep improving it. We have strong incentives to continue to develop and maintain it.

[ReillyTevera]

@Kaizhe Our use case is that our clusters scale up and down periodically throughout the day in response to load (and other factors such as EC2 spot market prices).

With your current approach there would need to be something additional watching k8s node events that would trigger a resync on node add events. With a daemonset approach a new node would spin up, k8s would automatically schedule the daemonset pod onto the node, the pod would do a full sync of cluster policies to that node and then that node would be ready for apparmor-confined pods. With both approaches there is a delay between when the node is started until it is ready for apparmor workloads however with the daemonset approach the process that is "preparing" that node is running on the node itself and only needs to be aware of the node it itself is managing (and can therefore be simpler and more reliable due to the tighter focus). In this sense the daemonset is "preparing" the node for the appropriate workloads, like kube-proxy/CNI and is being treated accordingly.

[ReillyTevera]

@Kaizhe Also, after I opened this issue I became aware of sig-nodes seccomp-operator project. That project was very recently renamed to the security-profiles-operator as they have decided to additionally fully support AppArmor as well (and SELinux in a limited capacity).

[Kaizhe]

@ReillyTevera Yes, I was involved in the conversation with the security-profiles-operator team. We may integrate into it as well.

[tuxerrante]

Hi @Kaizhe, is this project dead or is there some fork alive in the wild?
It's the only solution I've found until now without the need of a privileged daemonset

[Kaizhe]

@tuxerrante Unfortunately I left Sysdig so I don't have the privileges to maintain this repo.