Re:DevOps Is Bullshit (2022)
by galleywest200 on Friday June 16, 2023 @09:10AM
(#36355977)
Having developers deploy the code to production is a security concern. You need permissions separated to ensure they do not sneak extra code into production after QA does their part. Our SOX audit was adamant about us changing this.
Re:DevOps Is Bullshit (2022)
by oldmanhorton on Friday June 16, 2023 @09:29AM
(#36356259)
Is this sarcasm? What's stopping whoever does have the permissions from "sneaking code into production?" This seems like something pretty easily addressed by a combination of code signing and time-gated permissions. A small dev team may not have the time or energy to stand those systems up, but a blanket statement that it's a security concern seems like a bit much.
SOC II and other audits tend to come with the same baggage- they want strict roles and separation of duties between operations and engineering.
> What's stopping whoever does have the permissions from "sneaking code into production?"
In our arrangement, the ability to push code to production is gated by the GitHub/Azure integration path. The QA or project person who is rotating the production deployment slots (azure functions) is not granted access in GitHub to deploy to those same functions.
So, the developers pushing code and those deploying code are mutually exclusive groups. You could still defeat this with collaboration between employees or screwing with AAD records, but that's why we have a ton of audit logging turned on too.
Re:DevOps Is Bullshit (2022)
by isbvhodnvemrwvn on Friday June 16, 2023 @10:31AM
(#36357142)
Having worked at companies like that - usually utter incompetence of 'release engineers'.
On the flip side, giving more people permissions increases the surface area for a social engineering or disgruntled employee attack. If your solution to sneaking code in is to delegate deployment to another team, now you have two teams that could sneak code in—one has to be sneaky and get around QA (not hard at most places), the other can just put the code in before deployment. Making the organization bigger isn't a great solution for lack of trust, it tends to exacerbate it.
Developer credentials should not be able to deploy to production, only CICD system credentials should.
Absolutely, you need proper controls in the system to control and authorize deployments with appropriate responsibilities in place, but fundamentally if your deployments are fully hands-off, it shouldn't matter who clicks the 'deploy' button
One thing that was very different was provisioning new machines consisted of ssh’ing in and installing the required packages and binaries. The deployment was probably a simple script that used scp.
However, once the term DevOps was coined almost immediately some people began to stop doing development work and just focused on automating operations work and constructing glorious crystalline castles in the clouds to handle traffic that could have been realistically served by 1U in a shelf somewhere. Complexity begets complexity.