my reflection on using service-mesh; after four years of avoiding it

-

 I remember i first heard the term "service-mesh" back in 2019. I could not understand the idea behind it at first but after some digging i learned that it provide certain capabilities while abstracting the underlying complexities. I then ran some prof of concept with Hashicorp Consul but i didn't find it appealing at that time. 

Since then I have been ignoring any opportunities for understanding and learning service mesh. I believe my desire to not use service mesh amplified after reading the great "Production Kubernetes" book by Josh Rosso where it explicitly recommends to NOT use any service mesh until you manage to get your workload up and running all the way into production and then you MAY consider the use of it. 

One thing that derived me away from introducing service-mesh in any project I worked at was that I felt it adds awfully a lot of complexities to an already complex ecosystem. Fast forward into 2024, I had an epiphany and realized having Service-mesh is essential for securing workload in Kubernetes. I have been working lately with Istio and have learnt it provides certain security capability that you can't have it otherwise without a service-mesh.

What made me change my mind?

I have been working lately a lot with security and compliance and something that I have realized and its widely accepted in the community is that is powerful as Kubernetes is as an container orchestrator, security is not its 1st class citizen. For instance:

  • Secrets in kubernetes are not encrypted by default.

  • any pod in any namespace can access any other pod in any other namespace by default.

  • communication between workloads are not encrypted by default.

when running any mission critical workload in kubernetes it would be essential to prevent lateral movement so that if one of the workload in the cluster gets compromised the attacker can't use that workload as jump host to access other workload that are running in the same cluster. or if two workloads are exchanging confidential information such as personal data, it would be essential for their communication to be encrypted even-though the communication takes place internally within the cluster and it doesn't go outside. Besides that, if having a Zero-Trust architecture within your kubernetes setup is on of your objective (which i believe it should), then having a mechanism in place that authorizes every inter-process communication becomes vital.

How can Service mesh help?

Service mesh plays an integral role in securing the kubernetes workload that is nearly impossible to achieve without it. with service-mesh such as istio you can easily achieve mTLS for communication between workloads thus ensuring all internal communications are encrypted. Besides that services mesh bring a sense of identity to each workload enabling workload to only communicate with the one that they are authorized to do so which is a characteristic of Zero-Trust architecture. 

There is relatively new feature of Kubernetes that is called "Network Policy" that one may think can do the job of service-mesh by preventing workload to call each other unless its explicitly permitted, but keep in mind that "Network Policy" act more similar to a traditional L4 firewall while service-mesh operates at Layer 7 therefore combining them can become a powerful force in securing cloud workload..

Comments

Post a Comment

Popular posts from this blog

Azure CNI vs Kubenet, What are the differences between them and which one to use?

-
Image
if you have ever deployed an AKS cluster, either through the Azure Portal or CLI, there is parameter that needs to be configured related to the networking part of AKS and that is to choose the networking model between  Azure CNI and  Kubenet. ( by default it's Kubenet as of writing this post) So what's this all about? in a nutshell this parameter is related to how Nodes and Pods gets their IP addresses assigned. It\s important to understand their difference before creating the cluster since you can\t change the networking model of your cluster once it\s deployed, and you defiantly don't want to re-create and re-configure your cluster again just because of this option. Overview of Kubenet and a few things to keep in mind This is the default options if you don't explicitly change it. With this option the cluster nodes gets their IP addresses from the VNET which your AKS is deployed to. This is not a big deal since the same thing happens if you go with the second option, ...
Read more

AWS EKS vs Azure AKS - my thoughts and reflection after using both in Production

-
Image
I am lucky enough to work both with Azure AKS, and AWS EKS(EC2), and I decided to dedicate a post on my blog about the two. I have also to admit that this is the most opinionated post I have written so far. I tried to put more emphasises on their differences than to write about their similarities. Here are the three areas I comparing them:  AKS vs EKS from Cluster Management Standpoint,  AKS vs EKS from Networking Standpoint,  AKS vs EKS from Scalability Standpoint AKS vs EKS from Cluster Management Standpoint  Both AKS and EKS mange the master node (AKA Data plane) for you completely, and there isn't much difference I notice in that area between the two. However, Azure does not charge you anything for the Master node it manage and you only pay for the worker nodes, however, EKS charge you a fix price monthly for that Master node (around USD 70 dollar depending on the region) One feature I like in EKS is called Managed Node Groups . This feature automate and off...
Read more

Architecting Kubernetes for High Availability, Fault Tolerance and Business Continuity

-
Image
Kubernetes can take care of many things, and can solve many problems except the ones it doesn't know about such as region failure and  human errors. In this post I want to compare and contrast the differences between Single Cluster setup spread across multi Availability Zones that is very common vs Multi Cluster Setup Spread across different Region . Hopefully by then end of this post you have some clue about when to use which setup no matter which cloud provider you are using; be it AWS, Azure, or GCP. Single Cluster Setup: In this Setup the Kubernetes nodes and their storages are distributed across multiple Availability Zones (AZ). This model ensures the nodes are physically separated from each other and the outage in one of the AZ will not cause the entire cluster to go out of service. At the same time the communication between each node is via private connection and does not route over internet no matter which cloud provider you use. I took the following image wh...
Read more