Cool, here is a VM without domain join and no access to internal resources. Feel free to use your admin permissions on there.
Seriously though: developers need admin access during prototyping unless you are a giant enterprise that already has CI\CD, dependency management, staging environment etc all set up and properly configured. For everything else, devs should have their contained sandboxes with admin permissions
*and all those environments come with admin teams (devops, sysops, call them whatever) actually good at what they do. Because I have a long list of things to vent about exactly because:
you’re a dev, so fight us for access and permissions (edit: that I already have ssh access to prod servers and thus could wreak havok any moment if I wished to is completely ignored)
here’s a botched something you asked. It is not configured/improperly configured - well, who da fuq cares. Let’s have another kanban card for fixing this
Recently one of our devs was caught running Chrome portable (because he wasn’t given admin access), where he logged in to his personal google account and saved his company credentials, where they were promptly synced to his personal malware-infested home system and ended up in a paid dataset on the darknet. IT Security, InfoSec and Governance policies have to be written with this kind of employee behaviour in mind.
Incidentally him and his team had just complained loudly about MFA being required for our critical apps.
Well, that is bad all over. And also can be seen as an evidence towards “if someone requires access that does not look suspicious, give it to them”: he wasn’t given access, so he went another way and fucked up spectacularly. On the other hand, though:
if it is a company machine, then not having admin access can be expected
I would expect that “do not ever use personal accounts for work and vice versa” does not need reminding, but here we are
yeah, the rules should account for malicious behaviour, intended and not
What’s relay funny about WSL2 is how you can be root in Linux but the whole WSL is still just a windows process with user permissions. So root!=administrator. Its actually pretty smart. Like root in podman container or in rootles docker.
Cool, here is a VM without domain join and no access to internal resources. Feel free to use your admin permissions on there.
Seriously though: developers need admin access during prototyping unless you are a giant enterprise that already has CI\CD, dependency management, staging environment etc all set up and properly configured. For everything else, devs should have their contained sandboxes with admin permissions
*and all those environments come with admin teams (devops, sysops, call them whatever) actually good at what they do. Because I have a long list of things to vent about exactly because:
Most of the damage is done with good intentions.
Recently one of our devs was caught running Chrome portable (because he wasn’t given admin access), where he logged in to his personal google account and saved his company credentials, where they were promptly synced to his personal malware-infested home system and ended up in a paid dataset on the darknet. IT Security, InfoSec and Governance policies have to be written with this kind of employee behaviour in mind.
Incidentally him and his team had just complained loudly about MFA being required for our critical apps.
Well, that is bad all over. And also can be seen as an evidence towards “if someone requires access that does not look suspicious, give it to them”: he wasn’t given access, so he went another way and fucked up spectacularly. On the other hand, though:
I’m forced to use windows to work. but having wsl2 with root makes it almost bearable.
What’s relay funny about WSL2 is how you can be root in Linux but the whole WSL is still just a windows process with user permissions. So root!=administrator. Its actually pretty smart. Like root in podman container or in rootles docker.