On Fri, Jun 23, 2023 at 4:07 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: > > >> applications meets the needs of these PODs that need to do > >> privileged/bpf things without any tokens. Ultimately you are trusting > >> these apps in the same way as if you were granting a token. > > > > Yes, absolutely. As I mentioned very explicitly, it's the question of > > trusting application. Service vs token is implementation details, but > > the one that has huge implications in how applications are built, > > tested, versioned, deployed, etc. > > So one thing that I don't really get is why such a "trusted application" > needs to be run in a user namespace in the first place? If it's trusted, > why not simply run it as a privileged container (without the user > namespace) and grant it the right system-level capabilities, instead of > going to all this trouble just to punch a hole in the user namespace > isolation? Because it's still useful to provide isolation that user namespace provides in all other aspects besides BPF usage. The fact that it's a trusted application doesn't mean that bugs don't happen, or that some action that was not intended might be attempted (due to a bug, some deep unintended library "feature", or just because someone didn't anticipate some interaction). Trusted here means we believe our BPF usage is not going to spy on sensitive data, or attempt to disrupt other workloads, because of design and code reviews, and we intend to maintain that property. But people are still involved, of course, and bugs do happen. We'd like to get as much protection as possible, and that's what the user namespace is offering. For BPF-side of things, we have to trust the process because there is no technical solution. Running outside the user namespace we also don't have any guarantees about BPF. We just have even less protection in all other aspects outside of BPF. We are trying to improve our story with user namespace to mitigate what's mitigatable. > > -Toke >
