The big promise of microservices is freedom – freedom to break an application into disparate services that are deployable independently, freedom to build these distinct services with different teams through their chosen programming language, database, and tooling, and freedom to develop applications with minimal bureaucracy. But with freedom comes the onus to ensure security.

In a microservices architecture, applications are broken down into independent services, which implies more complexities and more services to secure. There are technology strategies to all of this, yet only people can effectively secure microservices. Developers take on more responsibility for operating their code (DevOps) and securing the same code (DevSecOps). This drives a different kind of behavior relative to design, the kind of monitoring and tooling you have, and how you interface with systems that are built using a microservices architectural style. After all, strong microservices security is guaranteed by three guiding principles: traceability and development, compartmentalization, and continuous security visibility. These principles make life easy for security professionals and developers.

Traceability

The first key to ensure security is to build it into your continuous delivery (CD) workflow. It’s within the CD workflow that you insert tests and restrict regions for deployment and also set time for such restrictions. Doing so automates service delivery and guarantees auditability. Don’t create a group of new tools and new dashboards that people have to use. Don’t create interruptions in their workflow. Rather, integrate with the workflows and tooling developers are using already. The tool that you use is not more important than how you use it. As you work with the developers’ preferred workflow and automate as much as possible, security teams can upkeep with the speed and agility benefits of microservices, while assuring security checks are well-placed.

Another common and well-known technique to guarantee that a new service doesn’t introduce security or other problems is by launching a “canary workload”. A canary workload refers to a new production workload launched to a limited set of users. If this workload doesn’t trigger any automated security alert and looks good, the CD tool automatically rolls it into full production.

Continuous Security Visibility

Irrespective of the size of your organization, it is impossible to have enough security resources to penetration test every application or look at all lines of code. And then, one of the basic attributes of microservices is that they speed up change within and between applications. When you have hundreds or just dozens of applications that undergo change all the time, you need not rely on people giving information in an accurate or timely manner. Instead, you need automation or employ service discovery tools.

Service discovery can be defined as a registry of running instances for one or multiple services. As you employ service discovery tools, you can measure the riskiness of a specific service based on how many other services are dependent on it. The more the services depend on that particular service, the higher is its risk score. You also need to check if that service is exposed to external Internet traffic. Automated security risk assessment thus helps you with stratification of risk, allowing relatively scarce security people to focus on the microservices with maximum risk exposure. The majority of microservice frameworks offer one or many choices for service discovery.

Compartmentalization

The principle of compartmentalization is crucial for distributed systems as well as the microservices that constitute them. There are two reasons behind this criticality. First, all security will probably fail at some point, which urges you to limit the blast radius of that failure. Second, you need to keep the data reserved only for those who need to know.

In the case of a monolithic application, things are lumped together. Services are not independent of one another. Developers thus struggle to iterate on monoliths without breaking things during the process with every breakpoint introducing new security issues. Monolithic applications have quite sensitive systems with a lot of inputs and outputs, i.e. attack surfaces. Applications that have a large attack surface can be secured, but it isn’t easy to do so. In addition, it is harder to verify that things are working as they should.

In the case of a microservices application, however, security is effective and better. Here, the “blast radius” isn’t the entire application, rather it’s just the individual services. There are various security-forward companies who choose to further improve on the security model with a token vault that stores sensitive data. Tokens map to this sensitive data and these tokens can then be passed around the application without the data itself moving. The token service calls crypto infrastructure that is placed between the token and the sensitive data, thus protecting the data. You can thus execute much finer-grained access control, making it quite easy to trace what’s happening.

#microservices architecture #microservices application #microservices