Is Security for Containers and Microservices the Same?
Containers and microservices are being rapidly adopted as they go hand-in-hand with modern application environments. Being an evolution of hardware and software utilization (respectively), they perfectly match and therefore – as often happens with new technologies – create some confusion around which is which.
Also, from an information security point of view, protecting containerized applications or microservices can be interpreted in two ways.
Containers vs. Microservices
Containers are a new way to utilize compute power more efficiently, by isolating processes and allocating them the exact resources they need to run. That includes each process’ own files and libraries it needs, while all containers at a single host share the same operating system kernel and drivers.
This model is more flexible and elastic compared to virtual machines (the former phase in evolution), and can be easily accessed during development, testing, QA – and even production phases – whenever required, without limiting the operation of other processes running in parallel. Containers can be rapidly scaled up or out when there’s a peak in demand.
[You may also like: 10 Commandments for Securing Microservices]
Microservices however, are an evolution of application software architecture. Unlike monolithic apps, which would have run all processes and functions whenever accessed, this new architecture allows dispersing the different functions (or code components) so each runs only when required, allowing a more efficient, scalable and productive utilization of the app resources, regardless of architecture.
This is why the two are a perfect match, and thus the rapid and broad adoption by DevOps worldwide who’d like to implement agile software development lifecycle and accelerate their CI/CD pipeline.
The combination of containers and microservices enables rapid and frequent deployments, quicker resolution of issues, and end-to-end automation of the environment. In most cases, this is done by an orchestrating system such as Kubernetes, which has become the de-facto standard in orchestration of containerized microservices architecture.
Container Security vs. Microservices Security
With the emergence of service mesh architecture, many new security technologies and approaches have arisen. And for good reason; there is a new risk that must be addressed.
In 2019, we saw several publications of vulnerabilities in container images. Therefore, there are a few startups (some recently acquired) that address that exact problem. They are protecting the container image, hardening the OS, the registry, and its operation (runtime). However, they do not secure the data transactions between external users and the microservices that these containers run. Neither external communication (North-South), or internal, usually between apps or microservices to each other (East-West).
[You may also like: Agile Security Is Now A Reality]
Unfortunately, relying on container security solutions to secure microservices from data theft attempts, via injections, access violations or remote scripting, won’t do the work. It requires a dedicated application security solution that looks into HTTP or HTTPS transactions and enforces security to prevent data leakage, denial of service, session hijacking and other common web-attacks.
In that sense, it’s worth mentioning that since these environments are usually designed by DevOps teams, whose objective is agility rather than security, any technology that cannot auto deploy, scale, or integrate with the orchestration system–or in other words, won’t enable the continuous deployment rather than slow it down–will not fit and will be pushed back.
