Search for a command to run...
I am Murali Doss, a Sr DevOps Advocate and Cloud Consultant. I am a long time open source contributor who cares deeply for open communities. Currently supporting CloudnLoud community for a good cause. Love to learn and share new technologies, especially with Cloud and DevOps. You can reach me on Twitter via @muralidoss5588
super
Thank you..
Please continueMurali Doss
API (Application Programming Interface) security is critical for protecting sensitive data and maintaining the integrity of systems and applications. APIs are used to connect different systems and applications, and as a result, they can provide a gat...
Well after months of deep slumber, away from social media networks, I had to return to Pune and adapt to hybrid working. I was browsing through meetup.com and was intrigued by one event from AWS user group Pune. It is AWS Reinvent 2022 -Recap on 21st...
Episode 2
Simplify Access Control and Enhance Transparency Over Your ML Projects
Episode 1
Introduction
Kubernetes is one such great platform for deploying complex applications using microservices. In this article, we are going to see how we can use Kubernetes to secure a typical microservices architecture.
Type of Kubernetes Service
In order to understand a better way to secure our cluster inside Kubernetes, first, we need to know the different types of Service that are available inside Kubernetes. Out of the three Service type, we are going to discuss here the first type that is the ClusterIP service which is the default service type (automatically considered when you are not specifically declare a service type). As the name suggests, this service type forms a cluster IP that the pods can communicate within the cluster and not from the outside world. This service type can be used when you don't want to expose your microservices to the outside world and this is the service which will be used only for internal communication between different parts of your cluster.
NodePort service is yet another type of service which is said to be an extension of the ClusterIP service. Unlike Cluster IP service, NodePort service is exposed externally and allows the outside traffic to communicate with the pods through the node’s port which is opened at the node level. Typically, the ports allowed are from 30000–32767. Anyone from the outside world can access the pods of the cluster using {NodeIP:NodePort}. The major challenge with this service is that it is immutable. Whenever the node restarts, the IP could be changed, and you may need to update the IP accordingly which is not feasible. And to eliminate this challenge, an extension of this service is introduced which is the load balancer service.
Challenges with Load balancer Service
The Load balancer in Kubernetes is one of the service types that distributes the traffic from the source to the relevant pods. But whenever we use load balancer service inside Kubernetes deployment, it is going to expose all our microservices to the external world by providing an IP address using which anyone outside the cluster can access your microservices. This might not sound like a good idea when it comes to security for enterprise applications.
If you like to have a robust security measure for your cluster, you may refrain yourselves from exposing all your microservices to the outside world. Hence you need to understand the problems behind choosing load balancer as the service type, and what are the other options that we have inside Kubernetes deployment using which we can protect our microservices from exposing to the outside world.
As mentioned earlier, one such problem with the load balancer service type is load balancer is that when we deploy it, it is going to be exposed to the outside world. So, this is going to be a serious security issue within any enterprise projects. One another challenge with this service type is that it is going to have so many entry points in your Kubernetes cluster that becomes super complex to manage and also to implement the identity and access control policies in all these entry points and do an analysis of how many endpoints that you have and implementing security in all those places is going to be a tedious task.
Therefore, Kubernetes load balancer is not recommended for the enterprise production setup. Then which service is ideal for the Production environments and that points out to an API object called Kubernetes Ingress.
How secure is Kubernetes Ingress?
Ingress is an API object that helps to route the traffic from the outside world to the services inside the cluster using HTTP and HTTPS protocols. It eliminates the need of using multiple load balancer and acts as a single entry-point to the cluster.
Image from kubernetes.io
Kubernetes Ingress is more secure as it supports multiple protocols, path-based or content-based routing and provides a secure authentication mechanism. Ingress also provides URLs to the services to be able to access from outside the Kubernetes.
We can secure Kubernetes applications by creating a secret that includes TLS (Transport Layer Security) private key and certificate. Ingress supports TLS port, 443, and also performs TLS termination. It is possible for an NGINX ingress controller that would allow us to add OAuth2 authentication with relative ease.
Conclusion
Using of service type may vary from different use cases and scenarios. But when you are really concerned about Security, there are some common measures to be taken and tight guidelines should be followed. Some of them include using Transport Layer Security (TLS) for all API traffic within and at the edge of the Kubernetes clusters, enabling Role-Based Access Control (RBAC), using third-party Authentication for API Server, hardening node security, enabling audit logging, trying to use more granular network policies and try to upgrade to latest Kubernetes version as much as possible.
Follow me for more insightful blogs and information around Cloud, DevOps and Security!
