Microservices & Security
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.