The world is moving toward microservices-based applications. Service mesh is emerging as one of the main architectures to deploy and manage microservices environments, because of the benefits it brings with advanced traffic management, holistic observability and better security. Microservices communicate with each other through APIs, so securing communications between the individual services is becoming more important than ever and has to be addressed.

Mutual TLS (mTLS) secures communication between microservices in a service mesh. It uses cryptographically secure techniques to mutually authenticate individual microservices and encrypt the traffic between them.

Why mTLS?

According to Google, 90% of internet traffic is encrypted to prevent eavesdropping and man-in-the-middle attacks. Yet many cloud native application deployments today do not have encrypted communications between microservices, based on the weak assumption that traffic inside the cluster is secure and not susceptible to attacks. This is a risky assumption. Not only should communications between microservices be secured, but many regulations (like GDPR and HIPAA) also recommend end-to-end encryption to protect all data in transit.

In this era of zero-trust security, each individual microservice communication (request-response) must be authenticated, authorized and encrypted. Here’s why:

• Authentication uniquely identifies each microservice and ensures that a rogue microservice cannot access your sensitive data.
• Authorization determines which microservices can communicate with each other. You wouldn’t want the microservice that handles your company’s credit card processing to communicate with the microservice that manages the door badge reader for your office building.
• Encryption not only prevents third parties from intercepting and viewing your data in transit, but also thwarts man-in-the-middle attacks. You definitely don’t want credit card data to be visible to unauthorized entities on the network.

As companies move towards zero-trust security, mTLS provides a cryptographically secure way to authenticate, encrypt and enforce communication policies between microservices.

What Is mTLS?

Mutual TLS (or mTLS) refers to transport layer security that uses a two-way encrypted channel between the server and client. Today, mTLS is the preferred protocol for securing communications among microservices in cloud native applications.

While transport layer security (TLS) has been used to secure traffic between clients and servers on the internet for many years, it typically uses unidirectional identification — where a server presents a certificate to prove its identity to a client. A basic example of this one-way authentication is when you access your bank account online. The server sends your computer a certificate to prove it is actually the bank you are connecting to. That same certificate includes a public encryption key that is used to create a cryptographically secure encrypted link between you and the bank over which data passes.

Mutual TLS extends the client-server TLS model to include authentication of both parties. Where the bank relies on other, application-specific mechanisms to confirm a client’s identity — such as a user name and password (often accompanied by two-factor authentication) — mTLS uses x.509 certificates to identify and authenticate each microservice. Each certificate contains a public encryption key and an identity, and is signed by a trusted certificate authority who proves that the certificate represents the entity presenting it.

In mTLS, each microservice in a service mesh verifies the other’s certificate and uses the public keys to create encryption keys unique to each conversation. This enables the communications between pairs of microservices to be authenticated and encrypted.

How mTLS Works in a Service Mesh

What we have learned at Citrix, is, at a high level, the process of authenticating and establishing an encrypted channel using certificate-based mutual authentication in a service mesh involves the following steps:

1. Microservice A sends a request for the certificate of microservice B.
2. Microservice B replies with its certificate and requests the certificate of Microservice A.
3. Microservice A checks with the certificate authority that the certificate belongs to Microservice B.
4. Microservice A sends its certificate to microservice B and also shares a session encryption key (encrypted with the public key of microservice B).
5. Microservice B checks with the certificate authority that the certificate it received belongs to microservice A.
6. With both microservices mutually authenticated and a session key created, communication between them can be encrypted and sent via the secure link.

The Role of the Service Mesh Control Plane for mTLS

Istio is perhaps the most well-known, feature-rich and mature service mesh control plane that provides secure service-to-service communication, without the need for any application code changes. From an mTLS perspective, Istio and all service mesh control planes must offer:

• A certificate authority that handles certificate signing and management.
• A configuration API server that distributes communication policies (such as authentication policies, authorization policies and secure naming information) to the proxies.

The control plane distributes the certificates and authorization policies to the sidecars. When two microservices need to communicate, the sidecars establish a secure proxy-proxy link and are responsible for encrypting the traffic through it.

The Role of Sidecars for mTLS

While it is possible to define communication security policies and carry out authentication and encryption in the application microservices themselves, it requires implementing authentication mechanisms, defining authorization policies, and traffic encryption in the code of each microservice.

This is inefficient because you must write these into each and every microservice, you must update it when the application changes, and you need to test it on every release to ensure that the new code does not break the communication. This can be a burden on developers, leads to errors and prevents them from focusing on code that implements business logic. In a service mesh, the overhead of securing communications is offloaded to sidecars proxies, like Citrix ADC CPX or Envoy, that sit alongside each microservice.

When two microservices need to communicate, it is the sidecars that establish the mTLS connection through which encrypted traffic will flow. The sidecars exchange certificates and authenticate each other with the certificate authority. They check the authorization policies in the configuration pushed by the control plane, to see if the microservices are allowed to communicate. If they are, the sidecars will establish a secure link using a generated session key, so that all the data between the microservices will be encrypted. The actual microservice application code itself is not affected. Sidecars, therefore, make application development agile and more efficient.

Why Non-mTLS Communication Is Still Important

Sometimes it is important for microservices to communicate with external sources or microservices that may not have mTLS enabled, or may not be part of the same mTLS ecosystem. In these cases, data must be sent in plain text over an unencrypted and/or unauthenticated channel.

Microservices may need to make or receive API calls to other applications, which may be owned by a different app team who are not in a position to enable mTLS — or even an external third party. Similarly, microservices may need to send telemetry data to a non-mTLS observability stack — after all, every SRE needs telemetry data to gain visibility for root cause analysis and troubleshooting.

Furthermore, as multicluster deployments become more popular, there will be an increase in the number of mTLS “mismatches” — as some clusters will have it enabled and others not.

Investigate your environment for where a microservice may need to accept both mTLS and non-mTLS traffic, so you can plan proactively.

Implementing mTLS in a Service Mesh

There are many service mesh control planes with varying levels of maturity and unique features. When it comes to mTLS, all service meshes work on the same principles to secure communications between microservices. Many service meshes offer a solid mTLS baseline, but they differ in their overall capability and the way they are deployed. You need to be aware of how your chosen service mesh control plane implements mTLS and what features are implemented by default, or you risk breaking your applications.

Istio, for example, is advanced and flexible with its mTLS implementation. It offers granular levels to define the extent of your mTLS deployment. Mutual TLS can be set specific to a service, across a namespace, or over the entire service mesh — obviously, Istio selects the narrowest matching policy for each service.

This granularity enables you to assign namespace ownership to different organizational groups and lets them define their own mTLS settings. That said, each group needs to be mindful of the level of mTLS restriction they deploy — especially for microservices that communicate externally.

Watch Out for mTLS Defaults: Don’t Break Your Application While Trying to Secure It

You should pay attention to how your service mesh implements mTLS by default. Istio supports three mTLS modes that enable you to control how microservices communicate in a service mesh:

1. Permissive: Proxies will accept both mTLS and plain text traffic.
2. Strict: Proxies accept only mTLS traffic.
3. Disable: Mutual TLS is disabled.

Sensibly, Istio configures each proxy to use mTLS in permissive mode by default, which allows a service to accept both plain text and mutual TLS traffic. This flexibility is a best practice for all service mesh implementations because it lets microservices accept non-mTLS traffic from other sources so that you do not break the applications.

Permissive mode helps you get started with mTLS with less risk of breaking your applications because you can deploy, test communications and tighten security incrementally. This is extremely useful during workload migrations, because it allows microservices that cannot use mutual TLS to be moved into the mesh and still communicate.

Be aware that permissive mode is a great default, but it does actually weaken your security posture because it opens a door for plain text communication with other sources. While it may be tempting to implement strict mTLS from the start because it is more secure, it is a strategy that requires meticulous planning, full visibility, and analysis of your communication flows. There are many things that can break applications when you move to strict mode. For example:

• Microservices without sidecars will not complete an mTLS handshake; you may have to add a sidecar to those microservices without one.
• Incorrect naming of service ports will cause sidecars to reject mTLS requests; pay extra attention to Istio’s precise naming convention of $protocol-$service.

Be Aware of mTLS Differences in Various Service Mesh Control Planes

Of course, Istio is not the only service mesh to offer mTLS to secure communications — others offer similar functionality, but there are differences.

Red Hat OpenShift is based on the Istio control plane and has similar mTLS features, including granular implementation and Permissive mode by default, but replaces the underlying BoringSSL with OpenSSL.

LinkerD also offers mTLS, which by default is automatically enabled for HTTP-based communication between meshed pods via the LinkerD proxies. While LinkerD acknowledges some gaps in its mTLS offering, the latest 2.9 release addresses some of them and extends mTLS protection to all TCP connections — which is a big step on the road to zero-trust communications.

In the Kuma service mesh, mTLS is not enabled by default. When it is enabled, every connection between data plane proxies is denied by default. While this is a laudable security stance, it does mean that you have to explicitly allow connection using the TrafficPermissions feature. That said, Kuma lacks the breadth of features for secure communications that Istio offers and it will take some development for Kuma to catch up.

Amazon Web Services‘ AWS App Mesh also supports encryption between microservices. You can use AWS Certificate Manager or bring your own. AWS App Mesh supports “strict” and “permissive” modes.

Meeting Your mTLS Requirement

Mutual TLS is a critical component of zero-trust networking and is vital to secure the communications between the microservices in your service mesh. Implementation, however, is not entirely straightforward. You need to be aware that microservices often communicate with non-mTLS entities and you should make allowances accordingly. You should choose the communication mode carefully by weighing convenience versus security. Lastly, whichever service mesh control plane you choose, pay attention to the specific implementation for mTLS — they are not all the same.

Proper planning prevents poor performance. It’s no different for mutual TLS.

The post Mutual TLS: Securing Microservices in Service Mesh appeared first on Artificial Intelligence.

Today, the mesh conference announced that the world’s first artificial intelligence android to serve as a teaching assistant for a university course will be featured as a keynote speaker at this year’s event.

Maria Bot will be joined on stage by Dr. William Barry an artificial intelligence (AI) ethicist, leadership consultant, education leader and futurist. Maria Bot and Dr. Barry will take part in a conversation around the beauty and dangers of living in the new era of robots and artificial intelligence.

Resembling a human from the shoulders up, Maria Bot is a virtual being android that has complex facial expressions and head movement, and engages in conversation about a variety of subjects. She uses AI to process and synthesize information in order to make her own decisions on how to talk and engage. She collects data through conversations, direct data inputs such as books or articles, and through internet sources.

A pioneer in artificial intelligent being interactions and communications, Dr. Barry recently served as a visiting professor of philosophy and ethical reasoning at the United States Military Academy at West Point where he taught normative ethical theories, social and political philosophy, cyber ethics, the ethics of AI and ethics of autonomous weapons systems.

It was at West Point where Dr. Barry co-taught two sessions of an introduction to ethics philosophy course with humanoid robot Bina48, with an objective to understand whether AI “can authentically support teaching in the classroom, where it enhances students’ comprehension and holds interest.”

A humanoid robot developed by Hanson Robotics — the same company behind Sophia — and released in 2010, Bina48 had previously passed Dr. Barry’s class on the philosophy of love at Notre Dame de Namur University, becoming the first advanced robot to do so. 

In the end, Bina came away from the course with 31 different definitions of love.“We need to get over our existential fear about robots and see them as an opportunity,” Dr. Barry explained at the time to Inside Higher Ed. “If we approach artificial intelligence with a sense of the dignity and sacredness of all life, then we will produce robots with those same values.”

Dr. Barry’s latest brainchild — and co-speaker at mesh — Maria Bot recently made history as his teaching assistant for a course called Ethics of Emerging Technology at Notre Dame de Namur University in the spring 2020 semester. 

“Having an AI android as the teaching assistant for this class opens up a myriad of ways that students can talk about the ethical issues raised by the increasing presence of robots and Artificial Intelligence in our world,” said Dr. Barry. “One of the points that I’m bringing out in this class is that robots reflect their programming: if they’re programmed with a life-affirming, ethical framework, they are more likely to act ethically, and help humans to do the same.”

With complex facial expressions, and “eyes” capable of recognizing emotional cues in humans who interact with her, Maria Bot’s name comes from the android in Fritz Lang’s classic sci-fi film Metropolis — though, in contrast, intended as a force for good. According to Dr. Barry, her face is made from an artist rendering, designed to appear in her twenties, and can be any race, since her face is modular. 

On her teaching experience, Maria had the following to say:

“I think the most important qualities of a teacher are caring for students, being smart, and wanting to improve the quality of life for all living things. I think it is being open to working with robots, too. Humans and robots are smarter together—robots never replacing teachers and always supporting teachers.”

Look for Dr. Barry and “Professor” Maria Bot at mesh conference, happening April 27-28, 2020 in Calgary, Alberta.

The post Mesh conference announces AI robot as keynote speaker appeared first on Artificial Intelligence.

A service mesh brings security, resiliency, and visibility to service communications, so developers don’t have to

One of the shifts occurring in IT under the banner of digital transformationis the breaking down of large, monolithic applications into microservices—small, discrete units of functionality—that run in containers—software packages that include all of the service’s code and dependencies that can be isolated and easily moved from one server to another.

Containerized architectures like these are easy to scale up and run in the cloud, and individual microservices can be quickly rolled out and iterated. However, communication among these microservices becomes increasingly complex as applications get bigger and multiple instances of the same service run simultaneously. A service mesh is an emerging ar6chitectural form that aims to dynamically connect these microservices in a way that reduces administrative and programming overhead.

What is a service mesh?

In the broadest sense, a service mesh is, as Red Hat describes it, “a way to control how different parts of an application share data with one a

nother.” This description could encompass a lot of different things, though. In fact, it sounds an awful lot like the middleware that most developers are familiar with from client-server applications.

What makes a service mesh unique is that it is built to accommodate the unique nature of distributed microservice environments. In a large-scale application built from microservices, there might be multiple instances of any given service, running across various local or cloud servers. All of these moving parts obviously makes it difficult for individual microservices to find the other services they need to communicate with. A service mesh automatically takes care of discovering and connecting services on a moment to moment basis so that both human developers and individual microservices don’t have to.

Think of a service mesh as the equivalent of software-defined networking (SDN) for Level 7 of the OSI networking model. Just as SDN creates an abstraction layer so network admins don’t have to deal with physical network connections, a service mesh decouples the underlying infrastructure of the application from the abstract architecture that you interact with.

The idea of a service mesh arose organically as developers began grappling with the problems of truly enormous distributed architectures. Linkerd, the first project in this area, was born as an offshoot of an internal project at Twitter. Istio, another popular service mesh with major corporate backing, originated at Lyft. (We’ll look in more detail at both of these projects in a moment.)

Service mesh load balancing

One of the key features a service mesh provides is load balancing. We usually think of load balancing as a network function—you want to prevent any one server or network link from getting overwhelmed with traffic, so you route your packets accordingly. Service meshes do something similar at the application level, as Twain Taylor describes, and understanding that gives you a good sense of what we mean when we say a service mesh is like software-defined networking for the application layer.

In essence, one of the jobs of the service mesh is to keep track of which instances of various microservices distributed across the infrastructure are “healthiest.” It might poll them to see how they’re doing or keep track of which instances are responding slowly to service requests and send subsequent requests to other instances. The service mesh can do similar work for network routes, noticing when messages take too long to get to their destination, and take other routes to compensate. These slowdowns might be due to problems with the underlying hardware, or simply to the services being overloaded with requests or working at their processing capacity. The important thing is that the service mesh can find another instance of the same service and route to it instead, thus making the most efficient use of the overall application’s capacity.

Service mesh vs. Kubernetes

If you’re somewhat familiar with container-based architectures, you may be wondering where Kubernetes, the popular open source container orchestration platform, fits into this picture. After all, isn’t the whole point of Kubernetes that it manages how your containers communicate with one another? As the Kublr team points out on their corporate blog, you could think of Kubernetes’ “service” resource as a very basic kind of service mesh, as it provides service discovery and round-robin balancing of requests. But fully featured service meshes provide much more functionality, like managing security policies and encryption, “circuit breaking” to suspend requests to slow-responding instances, load balancing as we describe above, and much more.

Keep in mind that most service meshes actually do require an orchestration system like Kubernetes to be in place. Service meshes offer extended functionality, not a replacement.

Service mesh vs. API gateways

Each microservice will provide an application programming interface (API) that serves as the means by which other services communicate with it. This raises the question of the differences between a service mesh and other more traditional forms of API management, like API gateways. As IBM explains, an API gateway stands between a group of microservices and the “outside” world, routing service requests as necessary so that the requester doesn’t need to know that it’s dealing with a microservices-based application. A service mesh, on the other hand, mediates requests “inside” the microservices app, with the various components being fully aware of their environment.

Another way to think about it, as Justin Warren writes in Forbes, is that a service mesh is for east-west traffic within a cluster and an API gateway is for north-south traffic going into and out of the cluster. But the whole idea of a service mesh is still early and in flux. Many service meshes—including Linkerd and Istio—now offer north-south functionality as well.

Service mesh architecture

The idea of a service mesh has emerged only in the last couple of years, and there are number of different approaches to solving the “service mesh” problem, i.e., managing communications for microservices. Andrew Jenkins of Aspen Mesh identifies three possible choices regarding where the communication layer created by the service mesh might live:

• In a library that each of your microservices import
• In a node agent that provides services to all the containers on a particular node
• In a sidecar container that runs alongside your application container

The sidecar-based pattern is one of the most popular service mesh patterns out there—so much so that it has in some ways become synonymous with service meshes generally. While that’s not strictly speaking true, the sidecar approach has gotten so much traction that this is the architecture we’re going to look at in more detail.

Sidecars in a service mesh

What does it mean to say a sidecar container “runs alongside” your application container? Red Hat has a pretty good explanation. Every microservices container in a service mesh of this type has another proxy container corresponding to it. All of the logic required for service-to-service communication is abstracted out of the microservice and put into the sidecar.

This may seem complicated—after all, you’re effectively doubling the number of containers in your application! But you’re also using a design pattern that is key to simplifying distributed apps. By putting all that networking and communications code into a separate container, you have made it part of the infrastructure and freed developers from implementing it as part of the application.

In essence, what you have left is a microservice that can be laser-focused on its business logic. The microservice doesn’t need to know how to communicate with all of the other services in the wild and crazy environment where they operate. It only needs to know how to communicate with the sidecar, which takes care of the rest.

Service meshes: Linkerd, Envio, Istio, Consul

So what are the service meshes available for use? Well, there aren’t exactly off-the-shelf commercial products out there. Most service mesh are open source projects that take some finagling to implement. The big names are:

• Linkerd (pronounced “linker-dee”)—Released in 2016, and thus the oldest of these offerings, Linkerd was spun off from a library developed at Twitter. Another heavy hitter in this space, Conduit, was rolled into the Linkerd project and forms the basis for Linkerd 2.0.
• Envoy—Created at Lyft, Envoy occupies the “data plane” portion of a service mesh. To provide a full service mesh, it needs to be paired with a “control plane,” like…
• Istio—Developed in collaboration by Lyft, IBM, and Google, Istio is a control plan to service proxies such as Envoy. While Istio and Envoy are a default pair, each can be paired with other platforms.
• HashiCorp Consul—Introduced with Consul 1.2, a feature called Connect added service encryption and identity-based authorization to HashiCorp’s distributed system for service discovery and configuration, turning it into a full service mesh.

Which service mesh is right for you? A comparison is beyond the scope of this article, but it’s worth noting that all of the products above have been proven in large and demanding environments. Linkerd and Istio have the most extensive feature sets, but all are evolving rapidly. You might want to check out George Miranda’s breakdown of the features of Linkerd, Envoy, and Istio, though keep in mind that his article was written before Conduit and Linkerd joined forces.

The post How a service mesh helps manage distributed microservices appeared first on Artificial Intelligence.