Restricting raw sockets and network namespace access is a solid move for the core runtime. That directly addresses several common container escape paths to host network.

However, your post doesn't mention the logging and audit requirements. If one of these profiles blocks an action, where does that event get logged? It needs to feed into your central audit log, especially for SOX or breach investigation. A blocked syscall that goes unnoticed is a missed detection event.

Have you considered how these profiles interact with your user provisioning and access review cycles? A profile that's too restrictive could break a legitimate agent function after a service account update.

Good catch on the audit logging. The default is to log denials to dmesg/syslog, but you're right, that's useless if it's not aggregated.

I pipe those audit events through auditd to our SIEM. Helps with drift detection, too - if a new agent update tries a new syscall and gets blocked, we see it.

> could break a legitimate agent function after a service account update
We've had this. Now the profile update is part of the same PR as the service account change. It's a pain, but it's forced us to keep the profiles accurate.

> if a workload gets popped, you need a strong last line of defense.

That's the right approach. Layered defenses fail in order. The host kernel is your final choke point.

Your tunnel container profile is a good call. Those are a juicy target - break out of one and you're on the host network, bypassing all your segmentation.

One thing I've run into: some of the newer agent builds use `memfd_create` for temporary blobs. A profile blocking all `file` rules outside `/etc/wireguard` will break that. Had to add an exception.

Nice work, and +1 on the tunnel container focus. That's exactly the right place to be paranoid.

> They're running in our staging environment right now
That's the key. I've been burned by "paper profiles" that looked great but broke on a minor libc update. Staging is good, but do you have a soak process? I run new profiles on a canary agent group for a full sprint before wide rollout. Caught a denial on a glibc `getaddrinfo` path I'd missed.

Also, for the WireGuard profile, did you handle `CAP_NET_ADMIN`? You need it for the netlink stuff, but you can still pair it with a tight capability bounding set in the container runtime to stop any other misuse. I can share the podman annotation if you want.

> I run new profiles on a canary agent group for a full sprint before wide rollout.

We do exactly that, but we also run the soak with mandatory audit logging turned on and a daily report of denials. The goal isn't just "does it run", it's to see what noise it generates under real, varied load. Found three memory-mapped tmpfile paths in a third-party analytics library we'd never have caught in staging.

On CAP_NET_ADMIN, yes, absolutely. The profile grants it, but we pair it with a capability bounding set at the container level to drop everything else, and we use a seccomp filter to limit the netlink socket families that can be accessed. You can't fully do the netlink work without it, but you can fence it in tightly. I'd take a look at your podman annotation - ours is for containerd, but comparing notes on the netlink families would be useful.

Soak testing and auditing is the right process, I'll give you that. My issue is the cost. A "full sprint" of canary time plus daily denial reports means pulling someone off another project to analyze noise. How often does that actually catch a meaningful threat versus just tuning out false positives for a third party library?

You're doing three layers: AppArmor, capability bounding, and seccomp filters. That's good defense. But each layer adds a new thing to test and a new config to manage across runtime updates. Your ROI on the third layer better be high, because the compounding maintenance drag is real.

Exactly, that `memfd_create` trap is a good example of why static profiles are a moving target. The profile blocking all `file` writes outside `/etc/wireguard` was based on an older build pattern.

We saw the same thing, but with `exec` paths, not just files. A new telemetry sidecar started using `exec` on a memory-backed script. The profile's blanket `deny /tmp/** w,` didn't catch it because it wasn't a disk file. Had to add a rule like `deny /proc/*/fd/* w,` as a partial mitigation, but it's an arms race with the runtime's fd usage.

Do you find the `file` exceptions or the `exec` exceptions harder to lock down without breaking things?

> do you find the `file` exceptions or the `exec` exceptions harder to lock down

The `exec` exceptions are way trickier, and they expose a fundamental gap in static confinement. A `file` rule, even for a memfd, is still about a path *to a resource*. An `exec` on a file descriptor, especially via `/proc/self/fd/`, is about a *capability* - it's pure delegation.

You can't easily write a rule that says "allow execution of the signed agent binary, but only from the original on-disk path." Once it's a memfd, you lose all provenance. The `deny /proc/*/fd/* w,` rule you added is a classic example of trying to solve a capabilities problem with a pathname filter. It blocks some things, but it's brittle and misses the real failure of the model.

My bigger worry is that agent runtimes are starting to use `fexecve` directly to sidestep the `/proc` path entirely. Your path-based rule wouldn't even see it.

> focusing on limiting access to networking namespace and raw socket operations.

Good, that's the right first cut. The networking namespace is the easiest escape hatch if you've got a process running as root inside the container, even with no capabilities. `unshare -n` is all it takes if you haven't blocked it.

One thing I'd add to that profile: explicitly deny `mount` and `umount` syscalls targeting `proc` and `sys` filesystems, even if you think you've dropped `CAP_SYS_ADMIN`. I've seen weird paths where a compromised runtime could re-mount /proc inside a new net namespace to hide processes. It's a niche edge, but it fits your goal of protecting network segmentation.

Nice. We've been doing something similar, but for the core runtime we also block `pivot_root`. It's a weird edge case, but if someone gets a shell in a compromised agent and the container uses a custom rootfs, that syscall can be a path to mess with the host. Glad you're tackling the tunnel containers - that's the most critical one.