Kubernetes quickly became the new industry standard for many enterprises to deploy and manage services in the cloud. To name a few amongst many benefits that Kubernetes bring are the ability to deploy applications to multiple microservices so that when one service goes down, other services can operate without complete failure. Moreover, the ability to autoscale the number of pods depending on web traffic.
As great uncle Ben once said, “With great power comes great responsibility.” Before deploying Kubernetes cluster, it is important to design a secure architecture so there aren’t any vulnerabilities. One topic that many miss during the deployment is creating TLS tunnel for traffic between microservices. Let’s dive in closer and see where the problem lies and what we should be mindful of.
The lifecycle of web traffic usually starts with a request from the user who is accessing the web application through HTTPS request. HTTPS meaning that traffic between the end user and web application is encrypted so that man-in-the-middle (MITM) can’t have access to the data in-motion.
The traffic from the end-user makes a request to the application and then routes to the load balancer(load balancers are usually provided by cloud vendors). The traffic then make its way to the ingress gateway of the Kubernetes cluster. Up until this point, traffic is usually encrypted.
However, many clusters fail to integrate a certificate into their microservice. As a result, traffic between microservices uses unencrypted tunnel. During this vulnerable movement, if MITM gains an access to the unencrypted data, they will be able to see the critical information in plain sight.
Of course, many cloud vendors provide baseline security that prevents any hackers from accessing the network within the cluster. However, with the right tools and thorough information gatherings, this can be attack vector for MITM to access network in the cluster and intercept the sensitive data.
Almost all cloud vendors provide availability zones, deploying different resources into different datacenters to mitigate downtime in case one datacenter goes down, then another datacenter can be used as a back up. This is a great benefit to the application, but it also can be a drawback if the cluster does not support encryption for data traffic.
As the data flows from one availability zone to another, the unencrypted tunnels can be sniffed by MITM and can access all of the sensitive data. Even if the integration team configures the nodes to be in the same datacenter, there is no guarantee that those nodes will be in the same server rack. Having the nodes in different server rack can be vulnerable against traffic sniffing or traffic mirroring for internal staff with malicious intent.
Imagine if the data that was intercepted by MITM are personal identifiable information (PII) or payment card information. This can be a huge headache of lawsuits waiting to happen. To mitigate this incident from happening, implementing encrypted tunnels between each microservices as they make API requests are critical.
By doing so, it will ensure that when traffic is intercepted by MITM, data will be encrypted, rendering the data useless. This will ensure both availability and confidentiality.
One of the easiest way to do this is to introduce Istio, open-source service mesh that layers onto distributed microservice architecture, into your Kubernetes ecosystem. By deploying Istio-daemon in the control plane and with small configuration, Istio automatically adds envoy (proxy) into each pod.This allows proxy to utilize pre-configured mTLS tunnel, thus establishing HTTPS traffic flow between each API requests as it makes its way to the endpoint.
In closing, as many enterprises migrate their applications to the cloud, security should be a forefront when deploying multiple microservices. Industries are adapting the “Shift Left” strategy, putting security at the highest priority during the cloud architectural and migrating process. Although configuring each microservice adds another task on the checklist, this implementation can enhance security to prevent any repercussion in the future.
