[georgebarnett]

There are already examples companies which have folded overnight after losing creds and having everything deleted.

Removing root is not a trust issue - it’s a security surface area issue. You increase the number of audit points and attack options by at least an order of magnitude (1 admin : 10 devs).

In a small shop this might be acceptable, however in a large org it’s plain old insane.

If you believe that devs require root then that’s an indicator that your build/test/deploy/monitor pipeline is not operating correctly.

[andrewstuart2]

> If you believe that devs require root then that’s an indicator that your build/test/deploy/monitor pipeline is not operating correctly.

For one, I never said anything about root. I'm not sure anybody should have root in production, depending on the threat model. What I am saying is that the people who wrote the proprietary software being operated should be the ones on the hook for supporting it, and should be given the tools to do so, since they're the most aware of its quirks, design trade-offs, etc.

That means not just CI/CD and monitoring output, but machine access, network access, anything that would be necessary to diagnose and rapidly respond to incidents. That almost never requires root.

[georgebarnett]

I completely agree. Very well said.

[voidr]

If all I need to do is gain admin to my dev machine and then I'm free to nuke your production database, your company is doomed.

> If you believe that devs require root then that’s an indicator that your build/test/deploy/monitor pipeline is not operating correctly.

Or it might be an indicator that you are not relying on archaic and ineffective methods to protect your system.

[georgebarnett]

Who said anything about admin on a dev machine? I don’t give a flying shit about dev environments - they’re polluted with chaos.

We are talking about root in prod being granted and yet you seem to be intentionally misrepresenting this.

[yebyen]

Seconded that:

> Not getting root on your own machine as a developer?

was the origin of this thread, and there are tons of places where developers are not permitted root access to their own dev machines. We are not all talking about prod instances.

I have this conversation with my own counterparts in network / platform / infosec / application teams (I am an app dev), and in some cases the issue is conflated because dev environments are based on a copy of prod, and the compromise of such prod-esque data sources would be almost equally as catastrophic as an actual prod compromise.

If this is your environment, then don't be that guy and make it worse by changing the subject from dev to prod. Don't conflate the issue. Dev is not prod and it should not have a copy of sensitive prod data in it. If your environment won't permit you to have a (structural-only) copy of prod that you can use to do your development work unfettered, with full access, then you should complain about it, or tell your devs to complain if it affects them in their work and not such a big deal for yours.

Developers write factories, mocks, and stubs all the time to isolate tests from confounding variables such as a shared dev instance that is temporarily out of commission for some reason, and so they don't have to put prod data samples into their test cases, and in general for portability of the build. Then someone comes along and says "it would be too expensive to make a proper dev environment with realistic fake data in it, just give them a copy of Prod" and they're all stuck with it forever henceforth.

It's absolute madness, sure, but it's not misrepresented. This is a real problem for plenty of folks.

[voidr]

> you seem to be intentionally misrepresenting this.

Top level comment in this thread:

> Not getting root on your own machine as a developer?

Maybe I missed the part where this thread transitioned from dev to prod. I have no reason to misrepresent a stranger on the internet.