Better Security for Microservices
Better Security for Microservices – Microservice architectures offer many benefits. However, they also create new challenges, especially for web security. In this article, we’ll discuss these challenges, and some new approaches toward solving them.
When organizations adopt a microservice strategy, they usually follow an incremental migration process. Applications are converted into microservices one at a time; meanwhile, other infrastructure is maintained as it was previously.
As a result, as organizations bring more microservices online, they often continue to use their existing web security solutions. During the migration process, this makes sense. However, once the migration is complete, many continue to use these solutions. This is not a best practice; it exposes the organization to a number of problems.
The problems arise because most security solutions were not designed for microservice architectures. Typically, incoming traffic is filtered by a solution running in an external environment (i.e., a separate environment from where the applications and/or microservices are running). This can prevent engineers from correctly implementing modern architectures. Worse, it creates inherent compromises of privacy and performance. Let’s discuss these issues.
Traditional security solutions are designed to defend a perimeter. In the past, the perimeter usually involved a data center, while today, it is most often a cloud environment. But in both cases, the traffic flow is the same. All incoming traffic arrives at a defined ingress point on the perimeter, where the solution examines each request, and either blocks it or allows it in.
This worked well when all the protected applications and services were contained within a single perimeter. But for microservices, this is no longer true. Microservices are self-contained, which greatly expands the number of “perimeters” that must be defended. This can create an unfortunate design constraint; in situations where engineers would ideally break up a large application into many microservices, they might instead choose a suboptimal topology consisting of only a few.
Limiting the number of microservices might seem like a way to reduce the potential security problems, but it cannot avoid them completely. If every microservice can accept incoming connections from the outside world, then it also needs the ability to detect and block threats within the incoming traffic stream.
This places an enormous burden on developers, who can no longer focus solely on business logic; instead, they have to stay current on a complicated and ever-evolving threat environment, where attackers are continually improving their tools and capabilities, so they can include effective countermeasures. They also must implement full and robust authentication and authorization capabilities for each microservice that they create. And they have to keep all of this security logic up to date over time.
Other problems are observed when you consider the flow of traffic. Very few security solutions run inside the user’s environment; instead, traditional security products usually run on external infrastructure owned or controlled by the vendor. This means that incoming requests do not go directly to the user’s applications and services. Instead, they are routed to the vendor for processing, and only afterwards are they forwarded to the intended destination.
This compromises both privacy and performance. Privacy is compromised because the vendor must decrypt the traffic for analysis outside of the user’s environment. Performance is compromised because traffic does not flow directly to the intended application or service; instead, it is sent to the vendor first, which introduces routing latency. Additionally, each request must be decrypted by the vendor and then re-encrypted before being forwarded; this adds processing latency.
So far, we’ve discussed the general challenges that arise when trying to secure microservice architectures. Additional problems arise when we consider specific use cases. For example, containers are a popular way to deploy microservices. But containers introduce challenges of their own. For example, containers are usually ephemeral, with short lifespans. They typically use dynamic port assignments and have other characteristics (such as requiring shared access to host resources) that can make security policies more challenging to configure. And some of the popular APIs have, in some instances, insecure defaults.
So, given all these issues around microservice security, what can be done?
Solving the challenges
Fortunately, as microservices have proliferated, so have other technologies and practices which can help to solve many of their challenges.
One of the most important developments is the service mesh. This refers to a topology consisting of a number of individual (micro)services, each of which has an associated proxy. Each service communicates only with its proxy, and nothing else; the proxy is its interface to the outside world. Each proxy communicates with the other proxies in the mesh; depending on the architecture, the proxies might also be able to communicate directly with external entities. Essentially, the proxies comprise an additional layer of communication infrastructure that underlies all the services.
This “mesh” of proxies supplies many of the basic needs of large service architectures. The best proxies provide discoverability, observability, load balancing, retries, failover, and other important functions. A service mesh allows microservice developers to focus only on business logic, and ignore all these other necessities, because the mesh automates all of these other requirements.
A service mesh also provides an excellent opportunity for web security. Since each (micro)service communicates only with its proxy, then all incoming requests must pass through the proxy in order to reach the service. Clearly, the proxy is an ideal location for traffic filtering.
Furthermore, building web security into a mesh proxy solves all the problems described earlier. The services do not need to include security logic, incoming requests do not need to be sent elsewhere before being rerouted to their original destinations, traffic does not need to be decrypted outside the environment, and so on.
As a result, solutions are now becoming available which do this. For example, an open-source platform was recently announced that adds web security technologies to a certain popular proxy, which is not only the basis for many service meshes but can also be used in containers, ingress gateways, and other purposes. Other projects a development as well.
We see then that microservice architectures pose several security challenges, but these challenges can already be mitigated, and further progress is rapidly occurring.
However, many organizations are not aware of this, and they are continuing to use a suboptimal strategy based on traditional security solutions. In this article, we have highlighted the compromises that are included in this approach, and shown that they are now unnecessary. A growing number of alternate approaches are now becoming available, and we recommend that organizations investigate these various options in light of their specific needs.
Better Security for Microservices