Securing microservice environments in a hostile world


At the present time, there is a remarkable trend for application modularization that splits the large hard-to-change monolith into a focused microservices cloud-native architecture. The monolith keeps much of the state in memory and replicates between the instances, which makes them hard to split and scale. Scaling up can be expensive and scaling out requires replicating the state and the entire application, rather than the parts that need to be replicated.

In comparison to microservices, which provide separation of the logic from the state, the separation enables the application to be broken apart into a number of smaller more manageable units, making them easier to scale. Therefore, a microservices environment consists of multiple services communicating with each other. All the communication between services is initiated and carried out with network calls, and services exposed via application programming interfaces (APIs). Each service comes with its own purpose that serves a unique business value.

Within a microservices deployment, one must assume that the perimeter is breachable.  Traditional security mechanisms only provide a layer of security for a limited number of threats. Such old-fashioned mechanisms are unable to capture the internal bad actors where most compromises occur. Therefore, it is recommended to deploy multiple security layers and employ zero trust as the framework. This way, the new perimeter and decision point will be at the microservice.

In this day and age, we must somehow enforce separation along with consistent policy between the services, while avoiding the perils of traditional tight coupling, and not jeopardize security. We need to find a solution so that the policy is managed centrally. However, at the same time, the policy should be enforced in a distributed fashion to ensure the workloads perform as designed and do not get compromised.

Leave a Reply

Your email address will not be published. Required fields are marked *