By: Ran Ilany, Co-Founder and CEO Portshift
The term ‘service mesh’ is used to describe the network of microservices that make up an application, and the interactions between them (e.g., discovery, load balancing, failure recovery, metrics, and monitoring). Istio is currently the most popular service mesh open-source framework. It provides a solution to connect, manage, and secure microservices by providing behavioral insights and operational control over the service mesh as a whole.
The service-mesh fits nicely in containerized micro-service environments that use orchestration such as Kubernetes, Openshift, and Rancher, which quickly adopt and support the service mesh concept in general and Istio in particular. However, many applications use additional resources that are not containerized or managed by container orchestrators but interact externally with the clustered microservices. Popular examples are high capacity/persistent databases that run on VMs, managed storage or DB services from public cloud vendors (e.g. AWS, Azure, or Google).
There are significant benefits when including external resources inside the service-mesh. In addition to the inherent benefits the service-mesh provides (efficient connectivity, observation, and security), connecting these resources with micro-services inside the mesh will enable holistic access management policy and the implementation of Zero-Trust-Networks, encrypting the communication between the microservices and the external resources (traffic in motion).
Connecting External Resources with Service-mesh
Since the Istio 0.2 release, there is an option to connect external resources using the mesh expansion option. This option allows non-Kubernetes entities (running on VMs and/or physical “bare metal” machines) to be added to an Istio mesh running with a Kubernetes cluster. Deployment of “mesh expansion” has many prerequisite configurations, such as enabling IP connectivity to endpoints in the mesh (which requires you to share the same “private network” (VPN, VPC, etc.) and restricting the usage of managed DB services which enables access to the Istio control plane components. The expansion also allows for the use of a Kubernetes DNS server. In addition, the external resource requires a new DNS configuration and the configuration of a node-agent and Envoy proxy. These requirements are not always feasible or practical but even if they are, they require complex configuration changes.
Along with the operational considerations, there are multiple security considerations that must be addressed. The new connectivity requires an admission controller mechanism to authenticate and authorize access between elements inside the mesh and the external resource (which can be challenging w/o Kubernetes services). Encryption for the traffic between the external resources and microservices of the service-mesh is another challenge that needs special treatment in order to maintain a high level of security. With the increased adoption of service mesh deployments, these challenges need to be addressed.
Advanced Service Mesh security
With identity-based cloud-native workload protection, administrators use service mesh architecture to provide runtime security for Kubernetes clusters and their ecosystem. Modern runtime security is an intuitive and centralized way to govern Kubernetes microservices, both internal services within the Kubernetes cluster or between clusters and external resources. More advanced vendors create a dedicated authentication and authorization verification engine, allowing microservices to be extended and packaged with additional resources. Now, users can create a simple security policy that encrypts any Kubernetes service communication with a single click. The user deploys the platform inside of the service mesh with a single command.
Adding Kubernetes security requires the admin to add the Istio-injection label to all relevant namespaces (which is typically the common deployment mode). Now, the security platform is enabled inside the service-mesh cluster and one can easily proceed to create a holistic access management policy for micro-services and the external resources outside of the service-mesh.
The use of a network policy engine enables hierarchical rules that simplify processing significantly to make the implementation of policy structure efficient. Using two rules allow users to define which microservices are allowed to communicate with the specific external resource and define general rule that will block all other services from communicating with this resource. With Kubernetes and service mesh services, policy administrators can quickly define a dedicated policy for each Kubernetes service that requires connectivity.
With these simple rules, a secure environment between your Kubernetes microservices and external resources such as DB or storage elements can be created.
Istio, the popular service mesh for Kubernetes clusters provides significant benefits for advanced container use. However, since it allows an extension for non-Kubernetes pods and services, this option may be complex to set up, which in some cases isn’t feasible (for example, with managed cloud services such as DB or storage). In other cases, this requires a complicated configuration.
Using strong identity-based workload protection with a service-mesh control-plane facilitates seamless deployment and enables distributed security controls for service-mesh environments that enable a simple and intuitive extension to external resources.
About the Author
Ran Ilany is the founder and CEO of Portshift, a leader in cloud-native application security. Prior to Portshift, he was head of security infrastructure for Check Point Technologies and has held executive positions with Blade Fusion and MainControl (IBM). Ran holds a Bachelor of Science in Computer Science and Robotics from the Technion.
