Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth, I'm Lead Advisor and Senior Analyst with KuppingerCole Analysts. My guest today is Alexei Balaganski. He is Lead Analyst with KuppingerCole Analysts and he's working in all areas cybersecurity and beyond. Hi, Alexei. Good to see you.
Hello, Matthias, great to see you again.
Great to have you. And we have a topic for today which starts with the a bit provocative statement, why securing microservices isn't as straightforward as you might think. But to start with that and to think about how to secure microservices - What are microservices and what do they change?
Well, I guess we should probably start with explanation, like why are we talking about this today at all? Because I mean, microservices aren't definitely new. They exist for a good part of a decade already as an overall approach towards designing software in a way that it's easier for large developing groups. Basically the idea was that your earlier piece of software was a monolith, a black box which had to be developed like at once as a single unit. With microservices, you can do it in small bites. Basically you could say, okay, one functionality will be developed by, like if you're talking about like an online store, for example, we could say, okay, the shopping cart will be designed by a specialized group, while payment management will be handled by a totally different unit, while whatever the UI and the recommendation engine comes from a third place. So those groups can be working together, developing their parts completely independently, maybe even using different technology stacks, one prefers Java, the other wants Python. Like a huge [...] of whatever modern technology comes these days. And in the end you have multiple loosely coupled blocks which run independently. More often than not, they run in the cloud and they communicate to each other through some standard interfaces, like RESTful APIs, for example. And this has become very popular to run those independent blocks in containers for example. But of course, it's not a must, you can run half of your microservices as containers, while the other half would be just the native services offered by your cloud provider. Could be those serverless lambda functions or third party services, you name it. The idea here is kind of, you split your logic into tiny bits and they are developed independently. And of course this idea has been hailed as a huge paradigm shift in software development because it really helps you to reduce your time to market because you can parallelize things which you were simply unable to parallelize before. And at a large scale, you might end up with a fairly straightforward cloud native application, which comprises hundreds, if not thousands of individual microservices. So in a sense, you used to have one huge black box, now you have hundreds of tiny black boxes all just communicating to the world, but also communicating between each other using APIs and network traffic.
Right, as you've mentioned. So we have a concept which is like client server concept on steroids because all these components communicate with each other. They need to make sure that, just as a layman, I would say, yeah, they need to make sure that traffic is encrypted and at least that these systems are properly authenticated against each other. But that was a question that was raised to me before. Is it really necessary to secure microservices when they are purely internal? Is there such a thing like purely internal?
Oh, this is actually a really interesting, if not unexpected question because, well, we have talked about zero trust lots of times in different episodes of our podcast, or at our events, whatever, like Zero Trust is now the trend to follow. What many people seem to fail to understand is that zero trust applies here as well, because as soon as you split your application into independent blocks you no longer have your safe perimeter because all those individual blocks, they are maintained and operated by different teams, they are run on different platforms, they have their own vulnerabilities, many of those which are probably yet even are discovered. And they have, basically in the end, if you have 100 microservices, you have 100 times more attack surface than before. So, yes of course you have to secure every bit of internal communication between your microservices and it's absolutely out of question, the only question is how do you do that at scale?
Right. And I mentioned two aspects. The first was encryption in transit so that every traffic is encrypted no matter from where to where it goes, and that each component can properly authenticate via a token or whatever. And I can imagine that if not securely properly secured microservice is scaled up, you end up with scaled up security issues. So where should we look at? What are the aspects that we currently have to make sure that microservices are properly protected, that the correct measures are in place? Give us a few examples, please.
Well, first of all, again, you have to consider that your microservice powered application running in a public cloud is in a sense, or it represents a perfect analogy for your company, in the height of the COVID pandemic with individual people and teams working from different places connected to each other only through some very wonky means of communication. And I mean we have all agreed that VPNs do not work in those scenarios for people and of course, I mean if your communications are completely unprotected, like if you only do all your business over email, basically you will end up hacked 100 times over, within a week, right? Same approach in a way applies to microservices as well because each microservice has to represent a unique identity and each other microservice has to be able to verify that identity and make sure that it's communicating with the endpoint it's supposed to communicate with. Because more often than not, we are dealing with sensitive data here, with personal customer information, with financial records and so on. And again, it has to scale, it has to be secure and there has to be as little implicit trust as possible. Again, we are talking about zero trust. The same principle applies everywhere. So you mentioned, for example, traffic encryption. Yeah, that's of course, like one of the foundational basics, but that's not enough. Each communication between two microservices has to go through some kind of a mediation process. Basically, you have to ask a trusted third party, some kind of orchestrator, identity server, service mesh, whatever you call it, to make sure that those two parties can actually be trusted, that they actually represent the legitimate bits of your application, and they are secure enough to handle the sensitive data they're supposed to handle. And again, we kind of go back to a very simple and kind of obvious idea, and there are no specific security tools for microservices because there is nothing specifically, there is nothing unique about microservices on the technology level.
Microservices are still applications which communicate over standard based APIs. So obviously you need some kind of an API security tool, but not just your old school API gateway which would only secure your ingress and egress traffic to the world. No, this API security solution has to be able to scale down to secure every bit of communication between every of your hundreds or thousands microservices. Looking from a totally different angle, your microservices is probably run as containers on some kind of an orchestration platform like Kubernetes, for example. So you need your whole toolset of Kubernetes security tools. And again, those are complicated enough when you run like dozens of containers. But what if you have hundreds and thousands? They have to be able to scale seamlessly to handle the complexity. And the third and much bigger error in this whole idea of access management, like how do you actually ensure zero trust on the microservice level, you know, you not only you should be able to define some kind of security policies. So like, yeah, it has to be a legitimate piece of your software [...]. It has to be able to support fine grained access rights, so a [...] part of your application should only be allowed to do specific bits of functionality, but not some other bits which will be handled by a totally different microservice. This has to be able to scale to a cloud level at least, or ideally to a multi-cloud level, because normally, you know, you can absolutely run your microservice application with external third party services involved. And of course, as you just mentioned, encryption and other privacy and data security enhancing technologies are a must here. The question is, can your VPN do it? Probably not. Can your standard, low level, TLS protocol do it? Again, probably not. There has to be some kind of an additional layer of network based security involved. Are we talking about zero trust network access? Perhaps. Are we talking about some kind of a service mesh? Absolutely. But again, there is more than one building block here. And the idea that somehow microservices need less security than legacy applications is absolutely crazy. As we can easily have established, it's absolutely the other way around. Microservices security is much more complicated simply because it has to scale.
Right. And we're talking about the concept that it has been mentioned again and again a few years ago. It's security by design, it's privacy by design. So really, to achieve end-to-end security needs to encrypt the complete chain from the end user towards all instances of functionality and back again. And I think that security by design demands for what you just described. You've mentioned container security but containers in the end also rely on sources. Sometimes they are just fetched from Docker Hub or whatever where they come from. Security needs to be applied there as well. Otherwise you will maybe end up with compromised images being the core of your microservices. Is that something that is covered in these tools as well?
Well, surely you remember that quite recently we have discussed the Leadership Compass on container security I have published a few months ago where we went into considerably more detail about the complexity of container security alone. Yes, it is complicated because containers are not just images which are on a platform. They have this whole lifecycle when they are developed by one team, then kind of managed and built, if you will, compiled, whatever into the final image by probably a different team or some kind of automation and DevOps platform pipeline. And then they would go for a period of storage in a container registry and then they will be pooled and instantiated in a Kubernetes cluster or probably in a totally different third party public cloud environment. And so this whole lifecycle, they have to be monitored, they have to be secure, they have to be hardened. And of course, they have to be constantly kind of... you have to be constantly aware of what's going on at each step on that lifecycle. So monitoring observability are proactive and reactive security threat detection, threat mitigation, all those topics they apply here just for container platforms alone. But the same level of complexity, of course, applies to, let's say, API security as a specialized technology stack. And again, we also have a Leadership Compass published on that topic which can be found on our website as well. API security alone is a pretty complicated topic to discuss. It probably deserves like a full hour of a standalone discussion. And of course there was this much larger and broader topic of access management authorization. Well, that's what we do, that's our bread and butter at KuppingerCole. We have lots of publications available on those topics and we probably need like a multi-day conference to discuss just all those aspects in detail. But I think today you should probably focus more on the processes and not on technologies because as always, we can hear, yeah, DevOps is the solution, DevSecOps in the way to go, this is how you actually combine all those technologies together and then somehow it just magically works. And I really have mixed feelings about those statements.
On the one hand, they are absolutely true. To be able to kind of scale up your security to multi-cloud level, the microservice level of modern applications, you have to apply a different methodology to your whole development process. In DevOps and DevSecOps are exactly the step in the right direction. What I cannot absolutely agree with, is a statement that there is like one right way to do DevOps or to do DevSecOps. Or that it's kind of a dogma, like a specific methodology described or even patented by some company or individual. And you have to do it this way and not any other way. This I absolutely cannot agree with. DevOps and DevSecOps are just kind of sets of general guidelines, just like Zero Trust is just a set of general guidelines and there are so many different implementations of that. And I am pretty sure that any sensible development team, any sensible company who already does DevOps to a large extent and even does DevSecOps to a certain extent, and it has to be made clear that the way they do it is better by definition, because they know how to do it and they have hopefully at least partially assessed their own specific risks. And integrated those assessments and models into their processes. The only thing we have to realize is that this cannot be done just once. DevOps and DevSecOps evolve daily. There are always new threats, new risks and new risk models, which have to be studied and your processes have to be updated and tuned and optimized daily. If you stick to that process, if you make this evolution of constant optimization, the part of your daily routine, well, then you are doing DevSecOps the way it's supposed to be done. Good job.
Yeah, that sums it up perfectly. It's really about this monitoring, improving, constantly improving, applying all the technologies that you've mentioned, but embedding them in the process framework that makes sure that all things play together well and that you get to solutions that are secure as of today and will be secured tomorrow as well, because they have been adapted to newly detected threats. You've mentioned the Leadership Compasses, and I think there's lots of material around these topics at our website as these are combinations of existing technologies. Nothing new, as you've mentioned around microservice, it's just another deployment model. It's another way of packaging services. I think it's really important to start with the documents that you've mentioned. So really about the security when it comes to APIs, when it comes to the container security and Access Management, which is of course a topic that I'm highly interested in, but also secure, efficient, fast authentication for all these services so that this is not the bottleneck and that this is not the reason for going unauthorized and authenticated in these areas.
Any final words before we close down? Alexei, what do you recommend? Where to start looking at when it comes to improving your microservices security?
Matthias, I would say you are absolutely the right saying that, yes, the best technologies, they are already all there, they already exist. You just have to know how to combine them, how to apply them properly. I would say you really have to have a step back and kind of try to think a little bit on the higher level, strategic level, if you will. And again, zero trust, just those two words are extremely important here because if you understand zero trust and the really a short set of basic guiding principles applies to microservices and application development, exactly the same as applies elsewhere in cybersecurity. You would immediately see how you can combine the existing tools and technologies in a slightly different way to make your overall security much better. Again, as I mentioned earlier in a different presentation, Zero Trust is [...] way of cybersecurity, you just have to stick to a few simple principles. You don't have to reinvent the wheel. You just kind of rearrange your furniture in your house and let the energy flow freely. And the earlier you start doing that, the more secure you will be in the end. But on the other hand, there is no end to this process just because the repeats itself ad infinitum. There is no end to securing anything especially securing microservices. As soon as you understand that, as soon you make it to your part of your daily routine, you are okay, I guess.
Great. Thank you very much, Alexei, for these thoughts and for giving that insight because this is really an evolving area and we are working with microservices as of now. So again, head over to our website, pick out the right documents where you are interested in and where you'd think you could improve your security posture when it comes to regarding your microservices. Thank you very much, Alexei, and looking forward to talking to you again soon.
Thanks and goodbye.
Thank you. Bye bye.
