Hacker News Reader

Comment by freedomben | Hacker News Reader

Inside most production environments. I could use this today inside a Pod that isn't allowed root privs.

This won't work in most cases inside a Kubernetes pod, as the default seccomp policies don't allow creating namespaces within them. You can obviously relax the seccomp policies, but at that point you can also just give yourself the capabilities.

There are eBPF tools which will work, for example https://inspektor-gadget.io/docs/latest/gadgets/trace_ssl

In production environments that won't give you root access, you won't be exec'ing inside of a pod if you aren't an operator or sysadmin.

No, you are wrong. I would. The pod would be mine though.

In my particular case, I am an operator and sys admin, but I don't give myself root privileges without having to go through some serious hoops, which I only jump through if I really truly need it. If I want root, I have to actually change the kubernetes manifest yaml to allow elevation to root privileges. That's not something that can be done without getting others involved for code reviews and what not.

However, even in the case of general developers, it isn't true. Companies do restrict exec abilities, but we don't. Many startups are the same, because developers are expected to also troubleshoot and debug production issues. If you don't allow shells in pods, you are really binding the hands of your devs.

To be clear, I am not disagreeing with you. You are correct in many cases. But there are a number of exceptions in my experience.

Reply on news.ycombinator.com