CI/CD Pipelines for DevSecOps with Hybrid Cloud by Michael Fraser

Today Michael Fraser reviews his experience with DevSecOps and hybrid cloud deployments, specifically focusing on CI/CD pipelines. Michael spent nearly a decade in the US Air Force as an aircraft armament specialist on F-15 C/D fighter jets and as a cybersecurity engineer. He is the and has been the founder of five tech startups, and is . He is currently the co-founder and CEO of Refactr a DevSecOps automation software startup.

With traditional IT, we have built everything around racking and stacking infrastructure and then deploying infrastructure. It’s been project-based and uses the waterfall approach. Unfortunately, we haven’t been able to apply much automation to this traditional IT infrastructure through CI/CD pipelines.

To sum up the life cycle, in the traditional IT model, we procure, pre-configure, rack, and stack, and then we do the final configuration for infrastructure.

Now, traditional IT is seen as legacy. But even though it’s legacy, we need to apply automation if we want to be agile. Refactr’s solution is IT as Code; their focus is on using tools and automation as well as changing the culture to an agile organization. With this methodology, IT becomes IT as Code, and everything becomes software.

The Solution: IT as Code

In the traditional IT model, we need to realize that resistance is futile and we must automate. So, IT as Code requires DevSecOps. DevSecOps adds agile infrastructure as code to agile software development. 

This allows you to iterate quickly, whether it’s your infrastructure, application, or your security. Everything becomes code.

How DevSecOps Fits in IT as Code

DevSecOps is very promising. It provides not just an automated workflow but also an automated workflow with baked in security. This workflow allows the organization to securely bring services to their customers, iteratively and continuously.

The goal is to automate as much as possible, the outcome of this is a reduction in errors caused by manual configuration. DevSecOps also automates responses to alerts and events, which again reduces errors and manual labor while increasing response speed exponentially. Finally, DevSecOps enforces security programmatically instead of manually; security will never again be an afterthought.

From an IT as Code standpoint, as we create the pipelines in an as-a-service fashion, we move from manual to automated solutions. So, we use tools like Terraform, Jenkins, etc. As we bring these tools in, we move towards a continuous process.

There are four main requirements in a CI/CD pipeline:

1. Automation
2. Integration
3. Agile delivery
4. Security

Meeting these requirements helps bring automation and agility to the organization.

How Do I Implement a DevSecOps CI/CD Pipeline?

Does this all sound easy? At a high level, yes. But how do you get there, and what does it look like with a DevSecOps CI/CD pipeline?

In this DevSecOps Reference Architecture, you can see how complicated DevSecOps can get:

Depending on what you use, you may add four or five tools. Some organizations are using 10 to 15 tools in the pipeline to get the results they want. Suffice it to say that things can get complicated.

Let’s see how, for example, DoD architecture might look with DevSecOps.

Looking at the DoD architecture, we still pull in a lot of different tools to automate and cover all our bases.

As you can see, DevSecOps is complicated, and it’s an ongoing and dynamic process. You’re not only configuring your CI/CD pipeline, but you’re also looking ahead at new tools and services and deciding what you should be doing next.

Let’s simplify this view by focusing specifically on security.

A Closer Look at Security

If we home in on security, there’s still a lot of tools. From key management, compliance, and governance to analysis, security touches everything.

Another way to look at this is to look at the technology stack for DevSecOps. In the stack, five main components provide a solid base:

1. Infrastructure as code
2. Configuration management
3. API integrations
4. Security as code
5. Source control

Each component of this technology stack has different needs; you need to choose the appropriate tools to address these needs.

Moving onto continuous monitoring, we need tools for several layers.

1. Application layer
2. Service mesh layer
3. CI/CD layer
4. Platform layer
5. Infrastructure layer

With so many layers, you can see why it’s essential to have multiple teams and engineers involved. Again, different tools exist for each of those layers. You can chain these tools together to streamline your CI/CD pipeline.

Here’s an example of a DevSecOps CI/CD pipeline and the tools you might include in it:

Long term, you can also look at how you can pull these components and build different pipelines for different needs. This helps create purpose-built pipelines that can be decoupled in a hybrid approach no matter where you’re going to apply the pipeline.

Hybrid Architecture

When looking at a hybrid architecture, you can have a combination of on-premise environments and cloud environments. You have the same opportunities to use the tools discussed above.

Final Thoughts

In the future, software will define everything we build. Today, not everything can be built into a pipeline, but over time you’ll replace components you can’t automate with components that you can automate. So, even as you’re moving to the cloud in a hybrid approach, look for opportunities to automate where you can.

As with most things, don’t forget culture. Changing the culture of the organization, from the business side to the technical side, will increase agility for all.

This post was written by Sylvia Fronczak. Sylvia is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.

Photo by JJ Ying