Hacker News Reader

Comment by williamcotton | Hacker News Reader

For a brief moment about 15-20 years ago developers were actually doing operations work. The infrastructure was simple. Some monolithic app servers behind a load balancer, memcached, perhaps a master/slave SQL database but mainly big iron… and then someone coined the term DevOps to describe the process of automating the management of these services…

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.

View on HN

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.

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.

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

SOC II and other audits tend to come with the same baggage- they want strict roles and separation of duties between operations and engineering.

Having worked at companies like that - usually utter incompetence of 'release engineers'.

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

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.

Reply on news.ycombinator.com