Skip to content

feat: implement AppArmor profile serialization#116

Open
CarlMarstorp wants to merge 1 commit into
k8sstormcenter:mainfrom
CarlMarstorp:feat/apparmor-serialization
Open

feat: implement AppArmor profile serialization#116
CarlMarstorp wants to merge 1 commit into
k8sstormcenter:mainfrom
CarlMarstorp:feat/apparmor-serialization

Conversation

@CarlMarstorp
Copy link
Copy Markdown

What

Implemented writeAppArmorProfile which was marked as TODO.

Changes

  • Added apparmor_converter.go with conversion logic.
  • Added apparmor_test.go with test cases.
  • Updated writeAppArmorProfile in main.go to use the new implementation.

@entlein
Copy link
Copy Markdown
Contributor

entlein commented Apr 27, 2026

Hi Carl,
Is the idea to parse an SBoB from kubescape yaml into AppArmor profile?

I think, it would be more beneficial to define a standalone adapter that takes the yaml as input and produces AA profile as output. That way you can define what exactly you need from it.

With seccomp there is no explicit testing, since the bob tool tunes the yaml against certain functional/attack tests for each CNCF/FOSS project I work on. The parsing of an array of syscalls is a trivial matter. I dont think, its useful. But, I dont know what other people want to do, so who am I to judge.

This project only supports kubescape/nodeagent formats and tests against those. Other ebpf based, real-time daemons make sense too. I dont see the LSMs, though

@CarlMarstorp
Copy link
Copy Markdown
Author

Hi! Yes, exactly - the idea is to take Kubescape Applicationprofile YAML as input and produce an AppArmor profile as output, using the existing conversion pipeline in main.go.

I understand your point about LSMs having a different lifecyle and not being the core focus on the project. That said, creating AppArmor profiles are typically slow, so having the ability to automatically convert a recorded behavioural profile into mandatory access control policy could be useful for users who wants a static enforcement layer as a complement to the eBPF-based runtime detection.

I'm happy to explore a standalone adapter approach if you think that's a better fit. Or if you feel AppArmor output does not belong on this project at all, we can close the PR - just let me now what direrection makes most sense to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants