Monday, September 17, 2018

Istio - A Service Mesh for Microservices

A follow up to Microservices & Security post.

I spoke about using a tool such as Istio to secure and manage microservices. Istio released v1.0 on July 31, 2018 and currently is at v1.0.2 as of September 18, 2018.

Per the website: Istio provides behavioral insights and operational control over the service mesh as a whole, offering a complete solution to satisfy the diverse requirements of microservice applications.

The means Istio is an end-to-end solution to controlling a complex spider web of services through the usage of it's split architecture shown below.
Istio Architecture
Two of the largest befits to using Istio is automatic metrics and secure service-to-service communications. Istio will automatically grab a ton of statically information and logs for a cluster pushing that information to a dashboard (below) for developers and managers to view.

Istio Dashboard
The realtime graphs show exactly how the services are working within the environment to provide direct intelligent on system health.

Secondly, Istio provides secure communications between services by default. Pilot, Mixer, Citadel, Galley, and Envoy provide different parts of the security architecture. Each of these services runs within the VM cluster to provide a single set of functions but together protect the service mesh. You can read the detailed information on the Istio website.

Istio is not just for Kubenetes environment. According to documentation, this can be deployed in other cloud or on-premises environments. Microservices are expanding the zero trust model to cover individual services and protecting core functions and data from threat actors. Istio is a step forward in how these are managed, controlled, and secured in the complex cloud systems deployed today.

Sunday, September 16, 2018

Microservices & Security

Normal Attack Surfaces for Deployed Applications

A shifting paradigm from large complex applications built and managed as single entities on single servers or clusters to a more micro services. This complex applications contained many different services and provided, in some cases, many different ports to communicate to end users and other external applications.

Also, these applications had complex pipelines when going from prototyping to staging to quality control to production. On a security standpoint, the attacking any part of the application could lead to a full compromise of the application and host systems.

Virtualization of Servers

Virtualization technology has been around for years and still being adopted in companies to migrate their servers to virtualized hosts providing cost benefits, better disaster recovery, centeralized server management. VMware ESX/ESXi, OpenStack, Xen, and others provide technology to virtualize not only servers but also networking and security devices. Each of these software is a type-1 hypervisor (more). Type-1 hypervisors provide a thin layer of an operating system which manages the hardware for each of the virtualized servers allowing multiple servers (in most cases any guest operating system) to run on the system.

The attack surface for each of these machines does not shrink by moving it to one of these technologies. Virtual machine escape is a set of vulnerabilities where a bad actor compromises a virtual machine and uses a vulnerability to break out of the virtual machine and gains control of the host. You can read more on this attack here and here.

Administrators still need to patch each application and guest operating systems separately through the usage of different types of automation applications or manually. Companies would need to higher full time administrators to only perform system updates because of the frequency of operating system patches and updates.


Microservices provide a better solution to cut down the attack surface and manage updates within the system. For example, if the application ran fully on Red Hat Linux, then when you split each service into different containers, you run three different instances of Red Hat; however, each container uses the same base image. The base image can be updated and pushed to each container which updates the base system for the application.

Containers are similar to traditional virtualized servers (as above) with one notable exception: a single container should run a single service. As you split up each service, you create microservices. These microservices usually connect through the usage of IP addresses and API calls providing less communication ports opened for attackers to utilize. Compromising one service will not automatically provide access to another. However, virtual machine escape may still happen.

Docker and Kubernetes both provide containerized services. Kubernetes, along with containers, management of these containers (docker and native kubes) through orchestration.

Security in Microservices

Security in these containers at a fundamental level similar to any other system. Containers provide a few extra tricks to protect applications. Rapid deployment of patches and software upgrades provides consistent security posture for the base system. Also, the provide a easy way to chain containers for rapid deployment of an application where all development tools remain outside the final container. In keep these tools out of the production environment, companies provide less in-box tools for attackers to use to attack the system with.

Segregation of traffic has known protection method for networks for years; however, now same idea is moved into microservices and with tools like Istio, companies can ensure only the proper traffic is sent to the right services more easily then traditional methods relying on network and host base firewalls and proxies.

Microservices expand across different enterprises to help securing and managing global applications for the modern user.