This property also allows developers to address a microservice that starts acting up. The other microservices will continue functioning while the malfunctioning component remains offline; once the change is made, developers can independently modify and redeploy the element. Finally, their independent nature makes microservices highly scalable and easy to integrate with third-party services.
The trouble with microservices
Microservices do present their fair share of security challenges. For instance, they introduce complexity into the network environment that expands the attack surface. Indeed, microservices communicate with each other via APIs that don’t use machine architecture or programming language. Kong explains that this communication creates more attack vectors and increases the number of failure points which malicious actors can exploit. Such complexity also makes traditional security measures more difficult to enforce. A more complex network environment with more connected services generates more logs. That’s a problem, as greater numbers of logs help to conceal security issues that pop up on the network. Security personnel won’t be able to manually manage the logs in response. In response to these and other challenges, organizations need to adopt a different approach to securing their microservices. As quoted by Kong: … [W]e arrive at the priority of forward-looking security design. Far from indicating a “my way” approach from a siloed security authority team, we have come to a point in DevOps culture where all possible factors contribute to considerations that form the basis of a stable security policy and protocol formation process. Without knowing how everyone is going to be impacted inside their changing day-to-day team concerns by security practices, creating a good security design is virtually impossible. This begs the question: what form should this forward-looking security design take?
The way to go: A zero-trust model
The best security approach to take with microservices is to implement what is known as a zero-trust model. As noted by The New Stack, the philosophy behind this framework is “never trust, always verify.” It requires security personnel to authenticate and authorize every access request to a network resource at all seven security layers. No connection attempt — not even those emanating from within the network — is automatically trusted. The zero-trust model is well-suited to securing microservices because it extends beyond just questions of authentication and access. It also addresses shortcomings of the traditional perimeter security model where a device typically trusts other devices in its own network and where authentication is minimal. Ambassador made this point in one of its whitepapers: The perimeter security model typically defines a small number of network segments, each of which contains many resources. The zero-trust security paradigm applied to a microservice-based application uses microsegmentation, which means a large number of network segments, each of which contains few resources (microservices). Microsegmentation helps minimize what each entity in the application ecosystem can access. Acknowledging this fact, organizations can work to implement a zero-trust model for their microservices by first identifying their sensitive data and determining where it resides in the microservices infrastructure. With an ever-evolving asset inventory and a data classification process in place, they can follow TechTarget’s advice to create multiple layers of security. Those levels should include network microsegmentation, but they should also use access controls and other measures to cover DevOps application delivery processes, as well.
Creating a zero-trust network
Organizations could very well implement access controls, set up network microsegmentation and maintain an asset inventory on their own to implement a zero-trust network. But they could waste a lot of time and resources in doing so — especially if they have many new connections in their microservices environment. What they need is a tool that can help them deploy the security controls that can help foster zero trust in their networks. Fortunately, there are plenty of solutions available that can help organizations to build a zero-trust network. For instance, they could turn to Istio. This service mesh comes with three important capabilities, as noted by StackRox:
mTLS: Trust but verify – Short for Mutual Transport Layer Security, mTLS provides encryption over the wire as well as enables service-to-service authentication and authorization in a service mesh. Policy checks: Fine-grained authentication and authorization controls – Mixer helps organizations to add access control to applications in an Istio service mesh. This accounts for connections from outside the cluster. Egress traffic control – By default, Istio enables an organization to block traffic to all endpoints outside the service mesh. This property thereby requires that administrators explicitly whitelist any valid external services.
Facilitating microservices with zero trust
Microservices help to drive business scalability and agility, but they also expand the attack surface. Organizations can address this risk by building a zero-trust network. In order to save time and resources, they can specifically use tools like Istio that help to streamline the process. You can learn more about Istio by visiting the tool’s GitHub page here.
