How proper networking supports microservices security

Why microservices security is a challenge

Traditional security and governance are based on proven identity. Applications have access requirements that users must meet based on who they are. The challenge of microservices is that a service composed into many applications might have many different access requirements. They might even serve as an accidental bridge between applications whose requirements are different.

Suppose a worker wants to access the company payroll records. If she works in that department and has proper credentials, access control tools would grant her entry based on, for example, a user ID and password. But if the payroll application is divided into a dozen microservices, a user could potentially access one payroll microservice and then gain access to confidential information. Each microservice might be protected via access control, but it's not ideal to require usersF to re-enter IDs and passwords for every microservice. This is where the network can help secure microservices without breaking the chain of free composition.

The explicit model of networking

It's normal practice to deploy applications within a private subnetwork, only exposing the external components or APIs. This is the explicit model of container networking, and this model has become even more prevalent as container use has accelerated. The model is actually helpful from a microservices security perspective, because it hides interfaces that should never be used external to the application. Further protection may even be unnecessary.

This model breaks down when applications are built from components used in multiple applications. , isolating these reusable components inside a private subnetwork means they can't be reused, so you have to expose them explicitly. The problem is that reusable components aren't really part of any single application; they're part of a pool of features.

It would make sense to deploy all shared microservices independently, meaning that they are all assigned to the same IP subnetwork. Then, they would either receive a public IP address so applications can use them or have their private addresses translated, typically to the address space of the company virtual private network (VPN). However, this makes them accessible to everyone, unless we further protect them.

API broker security vs. network-based security

One proven way to ensure microservices are addressable and secure at the same time is to rely on an API manager or broker to provide security. There are a number of strategies for securing microservices through an API broker; however, they generate overhead each time a call to the microservices is brokered. They can also increase the complexity of composing microservices into applications. As a result, teams should test API-based security and assess the consequences before they make a commitment. It's also possible to use the load-balancing and discovery tools associated with microservices access to add security, as the mechanisms and issues those tools address are roughly the same.

A second approach is to use network-based security. The applications that are authorized to consume microservices are almost certainly run in specific IP subnetworks, and the addresses that make microservice requests from these applications could be controlled and known. If traffic routing rules in the company VPN are established to limit access to microservices to the specific range of authorized application addresses, other traffic could not reach the microservices.

Either of these security strategies could limit your ability to dynamically compose microservices into applications, since you'd have to open your security gateway before the services can be connected. Security gateway processes can also make it harder to move changes through application lifecycle management processes, because, whatever you decide to use in production, you'll have to use in testing. Otherwise, your tests won't be reliable gauges of production behavior.

Microservices security and load balancing

You'll also need to examine the impact of microservices security on scaling and redeployment in case of failure. When a microservice scales, the additional instances have to be load balanced, which means your load balancer has to be accessible to client components and the microservice instances have to be registered with the load balancer. This can actually make things easier if the client components always link to a load-balancing function, since the load balancer is effectively a virtual microservice with a constant address. Load balancing also ensures work is divided up enough so that it's manageable and so that service outages are limited.

It's not likely that networking management practices alone can balance microservices benefits and risks. But that doesn't mean that networking can't help.

API brokerage and load balancing can be combined. In this case, the preferred approach is to place all the API brokers and microservices in a common subnet, so long as the broker supplies a security token to the calling application. If the broker actually makes the call to the microservice itself, place the microservices in their own subnetwork. Then, only allow traffic from the API broker to access the microservices.

Security depends on networking

It's not likely that network management practices alone can balance microservices benefits and risks. But that doesn't mean networking can't help, because microservices security should always contain a network-based component. If you hope to gain the full benefits of microservices, it's critical to accept that fact and work to optimize microservices security outside the network.