Containers are the preferred solution for delivering microservices, but they come with the cost of more security challenges than the Monolith system. The Monolith involves systems running in dedicated hardware, overprovisioning systems, and a handful of network connections (web tier, middle tier, and backend). Naturally, this produces several questions:
In modern architecture, network diagrams are no longer layered. In the era of microservices, it’s more of a mesh that’s dynamic in nature.
Despite this, network infrastructure is still one flat box. It’s hard to penetrate a network, but once you enter, it’s a flat world in the mesh of microservices. This means that a network rail guard at the edge isn’t enough to limit your services' boundaries and accessibility. A network intrusion by any compromised services can bring the entire island down.
Fortunately, several solutions (like Envoy proxy in Istio, or Finagle & Jetty in Linkerd) provide solutions to the above questions. Service Mesh provides a single pane of glass for all management and observability. The beauty is that it’s language independent and comes as an operator sidecar stack rather than libraries baked into the code.
The end goal of a Service Mesh is the ability to talk to another service securely in a controlled fashion that supports transparency and observability. It’s a concept that facilitates the basic principles of microservices:
We’ve heard clients ask why Kubernetes itself doesn’t come with a service mesh. The answer is that Kubernetes promotes microservices architecture using the service construct. Services are wrapped in containers (usually docker containers) and further repackaged to the pod with the container, volume, and network namespace. Lastly, a clustered pod (a.k.a. deployment) is exposed with a well-defined API using basic L4 load balancing services. ServiceMesh solves the higher-level problems such as using L7 load balancing with the visibility and security construct.
Another common question we hear has to do with the role of the Network Policy in Service Mesh.
For your convenience, we’ve broken down the differences between the Kubernetes Network Policy and Service Mesh below:
A recent report from CNCF shows that Istio is by far the best choice and covers most of the requirements of a service mesh.
At this point in time, all the capabilities of Istio have been outlined. Next, let’s see how Istio can help to solve high-security requirements like PCI standards.
For PCI DSS compliance, there are six major requirements that companies must follow:
Let’s review each of these in more detail.
As mentioned earlier, maintaining a secure network in a microservice mesh can’t be achieved with network firewalls alone. Microservices in general are mortal; they could auto-scale up or down based on load. IP addresses assigned to a pod could get reallocated to other pods once the current pod gets evicted.
The point is in the world of microservices “IP-IP” firewall is a NO-GO. It needs to move to policy-based “application-to-application” firewall with application identification. Again, service meshes come to the rescue. Meshes provide a unique identity to each microservice for authentication, and based on the policy, they authorize microservice-to-microservice communication.
And in terms of maintenance, a service mesh provides centralized management of all policies using YAML with Kubernetes-supported declarative pipelines.
The biggest change in breaking up a monolithic application to a microservices-based application is changing the communication mechanism. The application must evolve from a language-based method call to an inter-process network communication protocol, such as HTTP, TCP/UDP.
This is why encrypting the inter-process network communication is so important. Service meshes provide out-of-the-box features to configure mutual TLS globally on a k8s cluster and provide data on transit, encrypted by default.
While Service Mesh doesn’t directly do vulnerability management, it can be easily achieved by container scanning software like Clair, SNYK, etc.
Microservices have specific security needs. mTLS defends against man-in-the-middle attacks and implements traffic encryption.
Fine-grained access policies also uniquely audit every action to ensure maximum security.
One of the biggest challenges of microservices is to capture metrics and data from thousands of microservices. This data is essential for tracing bad microservices and finger-pointing a problematic service out of the thousands of microservices currently running. Improperly-designed microservices often cause chain failures of multiple microservices and it make it even harder to locate the root cause of failures.
Service Mesh observability tools like Grafana, Prometheus, or Kiali provide a single log connection and visibility of the entire mesh. Tools like Jaeger, Zipkin, or Opentracing help distributed tracing backed by the centralized log collections from other tools like Prometheus Elasticsearch and Stackdriver. These tools coordinate to create a simple, effective system of network monitoring.
The world of microservices is impossible to manage without having networking and security as declarative policies, backed by immutable security. This extends to network security policies as well. All policies in the Service Mesh are declarative policies using YAML.
Finally, we come to Zero trust security. It’s not just some buzzword; it’s a security requirement of microservices.
Zero trust security in Kubernetes Microservices can be broken down as the following concepts:
At its core, the Service Mesh security stack provides identity, policy, TLS encryption, and AAA (authentication, authorization, and audits). Taken together, this stack protects the application, data, and network, building a zero trust architecture all within Kubernetes.
While the above rundowns offer a good starting point for microservices security, the concept runs deeper. For microservices, a Service Mesh can be added as an “onion” layer security model to create a truly zero trust architecture in your enterprise. For more details, check out https://istio.io/ as well as the tutorial.
At Microstack, we specialize in best practices and solutions developed specifically for the Kubernetes environment. Contact us to learn more about our in-depth Kubernetes security solutions.
Ready to take your Cloud, DevOps and Security to the next level? MicroStack is here to show you how.Get Started