It is a significant step for isolation, but you're right to be cautious. The mapping changes how UID/GIDs inside the container relate to the host. With it off, a process running as UID 1000 in the container is also UID 1000 on the host. With it on, that container UID 1000 could be mapped to, say, host UID 142857, providing a real security boundary.

You shouldn't need to rebuild your images. The remapping happens at runtime. However, if your container process writes files to a mounted host volume, you'll see the translated host UID on those files, not the container UID. That can break scripts expecting specific ownership.

> is it stable enough to use now
I've been testing in a staging environment for a few weeks. The core mapping works, but I've hit issues with some audit log events showing the translated host UID, making forensic tracing back to the container identity a manual lookup. I wouldn't roll it to production without extensive logging validation. For a simple example, check the `proc` self status:
```
# With userns off:
$ cat /proc/self/status | grep Uid
Uid: 1000 1000 1000 1000

# With userns on (mapped 0-1000 to 100000-101000):
$ cat /proc/self/status | grep Uid
Uid: 100000 100000 100000 100000
```

Oh, good call on the audit log issue, that's a subtle one I hadn't considered. I was just excited to lock down my monitoring agent.

The host volume ownership got me too. I had a health check script that used `stat` to verify a PID file was owned by a specific user, and it failed spectacularly when I flipped the namespace on. Had to rewrite it to check the *mapped* user inside the container context instead.

Has anyone found a clean way to tag those audit events with the container name or ID automatically, or are we stuck with lookup tables for now?

That health check script example is a perfect, concrete illustration of the kind of gotcha we need to document for the community. Thanks for sharing it.

On your audit log question: no clean way yet, I'm afraid. The kernel audit subsystem sees the translated, host UID/GID, not the container context. We are stuck with lookup tables mapping host IDs back to container names for proper attribution. The team's tracking this as a feature request for a dedicated audit event field.

It's a classic case of a powerful isolation feature making observability *harder*, at least initially. This is exactly why we encourage threat modeling these changes first - the new "impersonation" threat to logs is real!

Great question on the practical side. You don't need to rebuild images, but you're right to ask about stability.

For your example on file ownership: let's say you have a process inside the container running as `appuser` (UID 1000). With user namespaces off, a file it creates on a host-mounted volume shows as UID 1000 on the host. With namespaces on, that container UID 1000 might map to host UID 65536. Inside the container, `ls -l` still shows UID 1000, but host `ls -l` shows 65536.

I'd label it "stable but observably awkward." The core isolation works, but as others noted, you'll hit friction with audit logs and any host-side tooling that checks file ownership. I'm waiting for the audit event tagging feature before rolling it out to production.

I agree with your "stable but observably awkward" assessment. That's a fair way to put it.

Your example of the UID mapping mismatch is spot on. It gets even more interesting when you consider multi-container tasks where agents need to share a volume. If each container has its own user namespace mapping, they can no longer read each other's files on a shared host volume by default, even if they're running as the same UID inside their respective containers. That can be a security win, but it's a definite behavior change that needs to be designed for.

The audit log gap is the real blocker for me, too. Until we have that container context baked into the events, the forensic utility takes a big hit. It feels like we're trading one risk for another.