Microservice Security and CD Pipelines How Much is Just Enough

Microservice security and CD Pipelines are changing how we approach DevSecOps. When we were all about monolithic development, security was all about the application version. Shifting the security left was a logical step to building out less risky and more secure software applications for end-users. In monolithic, the CD pipeline can be defined the same for all applications in terms of security steps and reviews. This is not the case with microservice security and CD Pipelines.

We must continue to advocate for tighter security policies early in the software life cycle. Also important to remember is that microservices are different from applications, and not all microservices should be treated the same. The first thing to understand about microservice security is not all microservices are equal. Security policies should be identified based on the type of microservice you are pushing across the CD Pipeline.

The DevOps @ Scale Problem

The problem to solve is DevOps @ Scale. With microservices, we are pushing lots of microservices across the continuous delivery pipeline all the time. For this reason, we must understand that they all cannot be treated the same. If we do, this means that every microservice must use a workflow that requires the highest level of review.

This approach could create unnecessary bottlenecks and developer frustration. When this path is taken, we risk application teams avoiding DevSecOps altogether. Developers begin to see security policies as unnecessary overhead. And this might be true for some services, but not for all. Microservice security and CD Pipelines require a careful balance between risk and control.

In other words, a change to a ‘front-end’ service that impacts a single application may not need the same level of security interrogation as a ‘log in’ service consumed by multiple applications. So how do we allow one service to pass through the pipeline faster than another service? DevOps @ Scale will require intelligence to understand how much is just enough to match microservice security and CD Pipelines.

The DevOps @ Scale Solution

To solve this puzzle, we must begin to create smarter CD pipelines. The pipeline should have insights into a microservice to determine the security policies needed. Asking the right questions such as ‘Who is using the service?’, ‘How impactful is the service?’, ‘What problem space does the service address?’ or ‘How does the microservice interact with data?’ gives us the needed intelligence to make the right decision about matching microservice security and CD Pipelines. In some ways, this is using classical configuration management to improve software delivery and security.

A Common Example

For example, a microservice that returns a list of all states does not need a high level of security. This service should be able to fast-track through to production with basic security applied, such as scanning. A service that returns a social security number should be locked down with the highest level of security policy possible.

For the second service, the CD pipeline will require additional security steps that may occur as part of or immediately after a deployment. We should be able to apply this type of policy to the social security service while allowing the service that returns a list of states to move across the pipeline as efficiently as possible.

Again, not all services are equal. We need a way to push microservices that are on the attack vector path applying the strongest security measures possible.  At the same time, we need to support ‘medium’ pipelines and ‘fast track’ pipelines.

 

 

Follow the Data to Improve Adoption

Certainly, the security ‘purist’ may argue that every container should have the highest level of security policies applied. But keep in mind it is adoption and acceptance of the DevSecOps process that is critical. Justifying to developers that their simple standard error messaging service must go through a super strict security pipeline is hard.

The truth is developers need to push some services fast. Operation teams do not have the insights into what a service does, so they want to apply the highest level to all services. Intelligence needs to be built into the delivery practice allowing attributes of a microservice to determine which workflow a service requires. In other words, we need the ability to both classify microservices based on a Domain-Driven Design and collect data about their usage to automatically determine the workflow required. Just like any science, following the data provides us with the answer.

DeployHub and Event-Driven Pipelines to Solve the Problem

It is time to make the CD Pipeline smart with DeployHub configuration data. In order to achieve DevOps @ Scale, pipelines must move away from a ‘one-size-fits-all’ approach. Classic configuration management practices can be applied to solving this problem. The most efficient way of addressing the problem is using automation and machine learning to determine the risk factor of a microservice that then determines the appropriate CD workflow.

To get to this level of automation, DeployHub is considering the addition of microservice risk assessments that can be used to determine the type of workflow required. Our microservice catalog tool has the ability to match microservice security and CD pipelines but CD Pipelines will need to adjust.

The Rise of Event-Driven CD Pipelines

Currently, most CD orchestration tools statically define the application data to the workflow logic.  In the future, workflows will become ‘event’-based allowing them to become dynamic. With an event-driven CD pipeline, DeployHub can use the classification of microservices, their access to data, their impact, and deployment success factors to help match the level of security required.

By following the data, we take the human factor out of the equation. When the decision is based on data, we can accurately determine the level of security policy needed for each microservice. We can then avoid the developer’s tendency to do too little and the operation’s habit of requiring too much. This is how we will achieve the balance between risk and control and make DevSecOps a first-class member of the CD landscape.