This is something I've had to consider a lot in the design of EnvKey[1] (a config/secrets manager). I agree that refusing root access on your own machine seems like it's going too far in most cases, but where's the line?

For example, EnvKey makes it easy to only give a developer access to development/staging config so that if someone only needs to deal with code and not servers, they'll never see production-level config.

Could that get in the way sometimes? Sure. If for whatever reason someone who's normally a pure dev needs to step into ops for a bit, they'll have to ask for upgraded permissions to do so, which could certainly be seen as annoying, and could make someone feel less trusted than he or she would like to be. On the other hand, giving production secrets to every dev undeniably increases the surface area for all kinds of attacks, and I think that even small startups would be well-served by moving on from this as soon as they can.

I think the key distinction to make is between real security and security theater. As a developer, I'm willing to give up a little trust and a little efficiency if the argument for why I'm doing it seems valid, but if I'm being asked to jump through extra hoops without any clear benefit attached, I'll probably resent it. So for me, the most relevant question to ask the OP (or a company that wants to implement this) is what's the threat model? What exact attack scenarios is this protecting against? Are those realistic enough to justify the extra hoops?

1 - https://www.envkey.com

Rootless containers are quite useful for things like accessing computing clusters which are shared and thus nobody gets root access on them (such as in universities). Rootless building is quite useful for other reasons (mainly because it allows you to build without ever hitting a privileged codepath which is arguably a huge security improvement), but to be honest it's more of a cool feature you can implement once you have the far more useful tools implemented (such as rootless storage management and rootless containers).

Fair enough, but there are cases where allowing that while also meeting the web of regulatory requirements that beset some industries is difficult if not practically impossible.

In layman terms, expect banks, defense, government and healthcare to have a dedicated operation team with root access. Developers do not have it.

I've seen that in a couple of IT outsourcing companies, too. Its hilarious because it complicates working with these companies so much that sometimes u just might reconsider hiring the company and do the work yourself. I dont think they realize how much they are shooting themselves in the foot with dumb restrictions like that.

Can you run VirtualBox and use it as your working machine instead?

If the VM is on the corporate network then it’s the same as connecting an unmanaged device - defeats the purpose of locking down machines. Developer VMs should be on their own VLAN.

Yes, but I think you are missing the point. Developers can access dev and production machines with non root users, root is never needed to run software.

If you are part of the sysadmins that really need root, to manage iptables or system updates for instance, you would have root.

I've locked down developer workstations before, to prevent things like "connect a USB stick and take a copy of data/code". We did allow running your own VM, where you could be root if you wanted.

In general, I've found it's pretty workable to run without root/sudo for development work - there's not _that_ much stuff that you can't just install to ~/bin and run from there.