How can we achieve high-grade security within a microservices ecosystem? Service mesh may be the answer
Enterprise applications often assign an identity to humans to determine security clearances. Using standards such as OpenID Connect and SAML, we can delegate authorization scopes across a suite of applications to determine precisely what a user is permitted to do. But what about the applications themselves? Some believe that microservices should follow this identity-first approach, too.
For large-scale application ecosystems, microservices is arguably more secure than a monolith. As Marco Palladino, CTO of Kong, described, “A monolithic application is a security incident waiting to happen.” Yet, microservices shouldn’t necessarily trust one another. So, how can we achieve high-grade security within a microservices ecosystem?
The answer may lie in service mesh. I recently met with Palladino to discover how a service mesh can achieve bank-grade security for established and emerging microservices patterns. Similar to how enterprises assign an identity to end users, a zero-trust security network gives an identity to microservices themselves.
A Zero Trust Network Trusts Nothing
With more personal data used in cloud operations, more and more personally identifiable information (PII) is vulnerable to attack, and the costs are high. In Q1 2019, the cost of breaches in the financial sector was $6.2 billion. In 2018, 97% of breaches exposed PII, a top target for cybercriminals.
Organizations are thus feeling pressure to secure their assets. The most precious data is held within financial services and health care, where GDPR and HIPPA enforce strict accordance with data privacy. This pressure is leading U.S. banks to clamp down third-party application access. Simultaneously, European banks face similar security dilemmas while appeasing PSD2 regulation for open banking.
To safeguard user data, organizations are adopting a zero-trust security model. “Zero trust security means that we’re not trusting anybody,” said Palladino. “We don’t trust our own services. We don’t trust our own team members.”
Placing too much trust in users, services and teams could cause a catastrophic failure. And, “there is no bigger risk than thinking you are secure, while in reality, you are not,” he said.
Monolith ⮕ Microservices
In practice, architecting a zero-trust application network runs parallel with the trend toward microservices designs. Though it may seem counterintuitive, a microservices system is arguably more secure than a monolithic architecture.
In a monolithic application, every resource—whether invoices, billing orders or transaction history—is always just one line of code away. Since everything is connected, you could expose a resource with a single access.
A microservices architecture decouples applications into separate services, each responsible for specific resources that make up the smaller applications, which can be secured and provisioned over a network.
Segmenting the service landscape avoids one cascading defect affecting all applications. It also enables more control. “By decoupling from monolith to microservices, we can apply fine-grained security permissions and rules to determine what’s possible in the context of the application,” Palladino said.
Microservices ⮕ Service Mesh
Implementing these permissions is where a service mesh comes in. The application teams often build security, yet it’s generally bad practice to build your own cybersecurity. Security for microservices requires high expertise, and standardizing connectivity between various microservices can easily result in fragmented security implementations.
Instead of building your own security infrastructure, Palladino recommended utilizing service mesh. By using service mesh as a control plane for microservices, platform architects can specify specific rules and attributes to generate an identity on a per-service basis.
Service mesh also removes the burden of networking from developers, enabling them to focus more on their core logic. “Application teams become consumers of connectivity, as opposed to the makers to this connectivity,” Palladino noted.
Identity for Services
In the same way enterprises create identity profiles for humans, Palladino said we must extend the same model to services, pairing each service with authorization scopes. “Services must provide their own identity,” he noted. “Based on that, they can do certain operations in their infrastructure.”
When we think of identity for services, attributes such as geographic location and certificates come to mind. These and other traits could make up a microservice’s authorization scopes. Utilizing a service mesh, architects could assign such attributes to each workload and service to determine what operations are allowed or what requests can be made to what other services.
For example, services from one region could be designed not to consume services from another region. Such attribute-based control for microservices is a novel, well-needed strategy, Palladino said. “It was crazy this was not in place before; not having zero trust is like having all your money in an open vault.”
Best Practices for Service Identity
Knowing that we want to implement identity-based security for microservices, where are some best practices? Palladino recommended:
- Automate some attributes: A service mesh could automatically assign identity attributes upon creation, such as cloud zone or geographic boundaries.
- Provide a way to manage attributes: A dashboard would be necessary for DevOps engineers to create, edit or delete service-level attributes.
- Governance: Architects must manage the control plane and create identities for the right parties to access this capability.
- Secure encryption and Mutual TLS: Teams will require a system for rotating and expiring certificates for hundreds of thousands of workloads running across an organization, noted Palladino.
- Standardize: Secure Production Identity Framework For Everyone (SPIFFE), a CNCF incubating project, is a good framework for service identity, making it operable with other cloud-native projects.
- Play nice with CI/CD: Attribute creation could be hooked into an underlying CI/CD process to occur when deploying products automatically.
Once microservices have identities, the services they interact with can determine what actions they are authorized to perform. This limits machine-to-machine communication to allowed operations.
Zero-Trust Security With One Click
Many teams have transitioned to a microservices architecture to deploy more often, be more distributed, decoupled or improve overall reliability. While these innovations are largely positive, Palladino cautioned against innovation without the proper security forethought: “It’s silly to transition to a microservices strategy without thinking about how these services are secured,” he said.
Teams will also be running microservices on various environments—VMs, cloud or physical data centers. Thus, considering microservice-to-microservice communication, how do we route traffic between such environments? How do we observe metrics and logs? Palladino believes an agnostic service mesh that supports multi-region, multi-zone, multi-cloud and hybrid modes is the answer to these dilemmas.
If used correctly, service mesh can plug security gaps for internal service-to-service communication, thus obfuscating high-value resources, such as financial services data, from nefarious players. The key to solving the service identity challenge is a usable dashboard. As Palladino described, “Zero trust security with one click.”
The data collected by the Instana agents injected into those microservices also will play a critical role in IBM’s overall approach to applying artificial intelligence to IT operations, also known as AIOps. The IBM approach to AIOps seeks to combine data from platforms such as Instana and Tivoli with 
