Segregation of Duties (SoD) in DevOps

Separation of duties is an important concept. It might seem to be incompatible with the DevOps approach, but it isn’t. In fact, in many cases, the separation of duties in the context of DevOps offers more assurance of quality, security, and auditability than traditional approaches. 

Someone else would test my code, someone other than me would review my code, several others would manually approve deploying my proposed change to production, and someone else would deploy my code. This is not the right approach. 

An Example of a DevOps Approach

Let’s get into an end-to-end example to see how the progression of code, from development to deployment, aligns with the goals of separation of duties in an organization using a DevOps approach. 

The developer works on the new application feature in a feature branch of the source. When it is ready, they issue a pull request, which requires one or more people to review the code and approve the merger of the new code back into the mainline. This includes the feature itself and automated tests. 

Once the code is checked in, a build is run that creates the executable modules that will be deployed to production. This is done via scripts and configuration. The build system puts the executable into an artifact repository. This delivery of the program is not done by a person, but by the build system. Individuals do not have permission to upload an artifact manually, helping to prevent tampering. 

Deployment from the environment to the environment can be triggered via a manual approval process or automatically based upon the previous step’s outcome. Either way, the deployment is also done by a script. At no time does a person manually move any artifacts or manually deploy code or configuration. 

Nothing is done manually except for approvals (and even they are automated from a workflow perspective). Scripts and configuration are responsible for all parts of the process. An “approval” is a manual step that also invokes a script. 

All scripts and configurations are peer-reviewed and go through a testing process before they are used. If there are manual testing steps, they are done by someone other than the person who wrote the code. 

So, how can a developer deploy their code to production? The answer is – they can’t. A script does, and the script’s integrity is reviewed by an independent person or a group of people. 

Here is the process of Segregation of Duties(SoD), as you can see below: 

Cloud Engineer

Gabriel Chutuape

A technology enthusiast passionate about automation, Gabriel Chutuape is a Cloud Engineer at ISmile Technologies. He’s part of the ISmile Technologies Cloud enablement team that help customers to design/solution/project engineering, integrating and implementing infrastructure technologies & services.

CLOUD Engineer

Gopi Krishna

I’m working as Cloud DevOps Engineer. Expertise in technologies of Kubernetes, cloud services and cloud-native services, and DevOps technologies in various clouds.

Register a Free Cloud ROI Assesment Workshop

Register a Free Cloud ROI Assesment Workshop

Get a Detailed assessment report with recommendations with an assessment report

Schedule free Workshop
Register a Free Cloud ROI Assesment Workshop
Register a Free Cloud ROI Assesment Workshop

Related articles you may would like to read

Leveraging Data Management Maturity Model to boost data management capabilities

Request a Consultation

Getting DevSecOps Right in Financial Services

Establish a culture of open communication, collaboration and shared accountability among all teams and stakeholders involved in the SDLC