Something is meshy around here
If you've read any technical articles within the last couple of years, especially within the discussions of microservices or Kubernetes, you'll have heard the term service mesh quite pervasively. Personally, whenever I think of a mesh, it's rarely a clean concept of machines communicating with each other. Usually, I think of the myriad of tunnels that have been buried underneath Boston, but that's another story. From a network perspective, however, a service mesh provides a way to securely connect your various services without requiring additional functionality within the applications themselves. But it still sounds kind of meshy, so why would I want to deal with this?
In the previous section, we talked about service discovery and how easy it is to determine where different applications and services reside, along with their health status. With that information, a bad actor can target the service for a variety of attacks and even service spoofing. For example, if I figure out that a particular application is connecting to a service, some sort of data store or provider, it would be possible to create a rogue service that the application would unknowingly connect to and potentially divulge sensitive information. Our ability to secure our applications has certainly improved over the past several years, however, the problem of imposters, cowans, and eavesdroppers has persisted, if not gotten worse, within a dynamic cloud world. And when this happens, it usually isn't good.
The Consul service mesh provides a networking model that ensures that all communication from service to service is not only encrypted but there is validation that the sender and receiver are actually who they claim to be. A great analogy for these communication systems is the postal system.
Let's step through the process of sending a package, something important that we want to secure and verify that it made it to the final destination:
- First, we're going to wrap the item we want to send in a box or envelope of some kind. On that package, we're going to place a label. Typically, that label will include the name of the person the package is destined for and their address. Note that this is a fixed address.
- We're going to hand that package to a postal worker…for argument's sake, we'll just call them Proxy. Proxy is going to make sure we are who we say we are, and because this package is important, we're going to tell Proxy that we need to make sure it goes to the right person.
- Proxy is going to potentially slap another label on the package and start moving the package through space and time. Since Proxy is local to your area, they aren't going with the package, but there is trust that the package will be protected along its journey.
The package may see all sorts of interesting things during its travels, but eventually, it will arrive at the name and address you intended. Proxy's distantly related sibling, Envoy, will validate that the package arrives at the proper location, based on the attached label. If we want to be fancy, we can even receive confirmation (such as an ACK) that it was delivered.
This simple analogy describes the communication within a service mesh. There is a message that needs to be communicated, but the application itself has neither the resources nor the intelligence to get that message securely to its intended destination. This is especially the case when that intended destination can change as, unlike our home address, we've already determined that we may not have the details of the destination address. So, the application hands that message to a local proxy, within the same machine, to eliminate the possibility of external snooping. That proxy has been configured with a certificate for two reasons. First, to validate its own authenticity. Second, to encrypt the message so that only those that are within the inner circle can obtain it. When the message gets to the other side, the receiving proxy can validate the certificate of the transmitter and unencrypt the message. From there, the proxy hands the message to the receiving application, again, on the same machine to eliminate any external snooping.
Figure 1.5 – Secure message transmission via the Consul service mesh
As we've seen, adding a service mesh into the Consul architecture enables us to not only discover our services but we can also securely, with validation, connect to those services. However, we may be using identical certificates within our network in order to validate and encrypt messages. This practice is not uncommon, and therefore opens the possibility of a rogue application within the mesh talking to whatever else it wants to. Well, we can't have that, so through Consul, we can create what's called an intention. When you create an intention within Consul, you're telling the associated Consul client who it can, and more importantly cannot, receive messages from. This provides yet another level of security within the service mesh.
OK, that service mesh stuff is a bit confusing, but I get it. Now that I'm not dealing with IP addresses, I can now set up connections between my applications and services that not only secure the message but also validate the sender. I can even control the communication within my own network by creating rules regarding who can talk to whom. But there is still all of this other network stuff that slows me down. Even in the cloud, I'm hit with delays with the firewall, load balancer, and other communication devices. Why can't we automate those pieces? Well, of course you can!