[ntnn]

Logging doesn't help you when you business has to shut down because someone took over you account and deleted everything.

Separation of access is important and _required_. Developers don't need access to prod, admins maintaining the infrastructure don't need access to the directory, IDM doesn't need access to either QA or prod.

Developers do need full access in an environment to properly test - but that environment should be basically hermetically sealed from the rest of the companies infrastructure. So even if they do screw up the whole business won't be affected.

[andrewstuart2]

If someone took over your account and deleted everything, and you couldn't get any of it back, you weren't taking care of the "availability" third of security. I agree that developers don't need access to everything, but I completely disagree that they should have no access to prod.

The games of phone tag and "try typing this" that happens during prod issues is a waste of everybody's time, and I fully believe that the people who write the code should be the ones with both the responsibility of the pagers and the ability to fix the code they've deployed. Everybody is happier, and the job gets done more quickly, when the job gets done by the people most qualified to do it (because they wrote it), and when they bear the consequences of writing bad code.

The environment needs to be set up to be forgiving of mistakes, yes, but that's easily done these days and should never result in loss of data if the infrastructure is properly automated. If giving production access means your developers can screw something up, then your admins can just as easily screw something up. Create environments that forgive these failures because they'll happen one way or another.

[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.

[IanCal]

As a dev, I love it when I'm not able to access production systems and poke them.