Source – techtarget.com
he emergence of microservices boosts business agility, enabling rapid application development, deployment and modification. The challenge is baking in microservices security processes. Traditional security processes can’t secure microservices, because the latter work in and communicate between both internal and external environments, according to Amir Jerbi, CTO of Aqua Security, a container security platform provider.
Using microservices makes security easier for developers or architects in some ways and harder in others. In this Q&A, Aqua Security Co-founder Jerbi offers advice on avoiding mistakes in setting up microservices security and balancing the often-conflicting needs for steel-trap security and rapid deployment of and communication between microservices.
What are the security pros and cons of microservices?
Amir Jerbi: Before cloud, you deployed your software on premises. You had to use the on-prem mechanism in order to secure your application. You had to use a firewall, host-based intrusion protection and maybe a code analysis tool and/or a tool to test for insecure coding. However, when deploying that app in the cloud, you had to use different tool sets and methodologies and build and deploy on one or separate cloud bases. With the shift to using microservices and containers, you can actually use the same tool set and methodologies to deploy on prem or in the cloud and even on every kind of cloud platform.
Microservices make it easier to develop an app that can run on multiple cloud platforms, because you’re using the same packaging and the same artifacts, and you can actually secure them exactly the same way. So, microservices can enable greater consistency in the way that you build, deploy and secure software.
What are some mistakes that could be made in developing and deploying microservices and building a microservices architecture that could lead to security issues?
Jerbi: With the monolithic architecture and application, all of the communications between different parts of apps would be internal. Now, to secure microservices, it’s more complex than that. You have multiple microservices running either on the same machine or distributed host, and there is a lot of communication between those microservices. Some of the communication can be on the same machine, some between different machines and some between different data centers.
When there are so many communications done between those microservices, it means that the perimeter is not something that is well-defined. You can’t put everything inside of a box and just protect that box. It’s not enough just to put a firewall in place, because all those communications must be governed and authenticated.
Easier app updating is a benefit of microservices. A developer can just redeploy a single microservice while letting the application run consistently. Doesn’t that require change management to be done differently than before in order to secure microservices and apps?
Jerbi: Yes. You need to make sure that the change that you’re adding to your system is controlled, and the software that is added doesn’t impact overall security of your application. Now, you need to manage so many small pieces, and that will require different mechanisms for authentication.
Microservice systems, many times, are open, allowing communication between the different services without any security control. So, it’s important to find ways to do strong authentication between microservices.
One way to do microservices authentication well is adopting a well-established authentication framework, like TLS [Transport Layer Security], and implementing two-factor authentication between all of the microservices. But to do that, you need to maintain new methods in order to publish security certificates and maintain those certificates. This is very different from traditional authentication, where they only needed to maintain TLS for the web server, which is much easier.
Are there other security perils that come with microservices?
Jerbi: There is a friction between the need for diligence in security and the need to make and deploy changes very, very fast because, well, you can and your competitors can, too.
Cloud deployment runs so fast today that Netflix and Google can roll out updates many times a day. Others want to do the same but often proceed without thinking through the security piece. The result can be pushing new changes into production apps without understanding the security impact of the change.
Traditionally, a security process ran slow. It required multiple intervals. It was a process that touched all along the pipeline. Now, people traditionally in charge of testing software and pushing it very fast to production are now also tasked with security — largely, securing the code. Wisely, many are taking the DevSecOps approach, wherein a group takes charge of security with a standard set of processes, such as two-factor authentication, RASP[runtime application self-protection], threat [modeling, etc.].
Which other approaches for securing microservices do you find useful?
Jerbi: Shift left testing is more focused on developers, and it allows you to do security analysis of your code or your microservices or your packages. Shift left allows you to fail fast and to fail the build, often to fail due to security issues. It might slow down development processes a bit, but it helps developers understand what’s needed from them in order to build applications with better security. Over time, the knowledge that comes from doing shift left will increase the level of overall security in the organization and allow faster deployment times. That’s because the code will be secure before deployment, and there won’t be after-deployment bottlenecks.