Analyst Chat
Analyst Chat #120: Leadership Compass Container Security
Securing containers along their lifecycle and wherever they are deployed is a cybersecurity challenge. And it is a new topic for KuppingerCole Analysts. Alexei Balaganski joins Matthias to talk about the just recently completed Leadership Compass on Container Security.
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 again - and I'm really looking forward to that episode - is Alexei. But I can see he's a Lead Analyst for KuppingerCole in the area of cybersecurity. Hi, Alexei.
Hello Matthias, thanks for having me again.
Great to have you. And as I mentioned, I'm really looking forward to today's topic. You've just recently published a new research document, a Leadership Compass, comparing different vendors in a specific market segment. And this the reason why we want to talk about that overall market segment and why it's actually required, why do we have it. We want to talk about container security. Why do we want to secure containers and what are containers?
Yeah, that's actually the most important question, I guess. Why are containers suddenly so important? I mean, if you go back 10, 15 years, containers were basically just another form of virtualization, a handy tool for developers basically to be able to run the apps in different environments without worrying about misconfigurations or different network settings, for example, stuff like that. Basically containers gave us, finally gave us that long term promise, which started probably way back with Java. It lets you run your app once and then run it everywhere without modifications. Well, yes. If you are old enough to remember Java which was its original promise, which failed miserably. But then suddenly the alternative came with the containers. And now, for whatever reason, containers are just everywhere. Of course, people are talking about cloud native apps and microservices, which are usually powered by containers, but the same containers can be run anywhere. I have some containers running on my computer at this very moment. I have containers running on the Raspberry Pi in my home development environment. And again, this is the same container image which I can upload to a public cloud. And it will work fine, or almost fine without any modifications. And this is why containers are so easily embraced by developers and of course, DevOps teams around the world because they are so easy to manage, so easy to automate the whole lifecycle. You basically just need to run the script to create a new image which contains everything necessary to run your app, push it through your CI/CD pipeline, upload to your cloud environment, just run it, and then basically ensure that it runs stable and fast enough and to scale it up when necessary. Containers are almost perfect for running modern apps. And this is everywhere.
Right, and when we talk about containers and securing containers, what is included in this securing? You've mentioned, you fire them up with just a script and then you deploy them wherever you want to have them. Where does security come into play here?
Well, that's exactly, again, the same old problem we had with other breakthrough technologies, like, for example, restful APIs. But security doesn't actually come anywhere because nobody started the quote unquote container revolution with security in mind. They were only thinking about convenience and scalability and clouds and all the other fancy stuff. Unfortunately, the understanding that containers have to be secured came somewhat later and somewhat later still came the realization that the traditional security tools like firewalls and IDS or whatever anti-viruses don't work with containers very well. First of all, because containers are ephemeral as opposed to like virtual machines, for example, containers can pop up around for a few seconds and then just disappear because they're no longer needed or you might suddenly spawn 100 copies of the same container image and then you have suddenly to somehow bring all those hundreds or thousands of new containers into your management and security console, for example. So unfortunately, traditional security tools do not work well with containers because they lack awareness of all those issues. Another thing to consider, as I mentioned, the whole container life cycle is usually at least partially automated because it always involves several disconnected teams. You have developers who create the app, you have some DevOps or infrastructure people who actually set up the environment.
And then there is somewhere in between who actually has to build the image, push it into some storage registry and then spawn it later for the run time and stuff like that. These are all different teams, different teams using different tools, and the only integration buzz between them if you will, called continuous integration, CI/CD pipeline. Which again isn't actually, which was never designed with security in mind. So we end up with this whole idea that containers have a very long and complicated lifecycle with different stages and phases which are taken care of by different people and somehow you have to include security at every stage and then make all those tools work together. So container security is complicated. It's much more complicated than many people think. And this is exactly the focus of our Leadership Compass.
Right. So the security process starts with keeping track of which containers are where, at which point in time, and then maybe monitoring. What are key capabilities when it comes to looking at container security, what where the aspects that you looked at when looking at the actual products that are provided for maintaining container security?
Well, when we are talking about containers, we're usually talking about container orchestration platforms, most famous one being Kubernetes, for example. But of course, every cloud service provider had their own platform. And there are famous cloud neutral solutions, like, for example, OpenShift from RedHat. Those are platforms and those are really complicated solutions that have multiple layers which go all the way down to the bare metal hardware and then networking layer, some support services, databases and other types of infrastructure. The actual orchestration capabilities themselves, which take care of moving your new container to a certain host, for example, make sure that it's actually running. And if it's not running any more, then kind of killing it and spawning somewhere else, all those resource management and monitoring and analytics and access management, this is all built into the orchestration platform tool. And then of course, you have to secure the actual container images themselves, because what if someone makes a piece of malware into your container image how do you deal with that? And then, of course, you have to somehow monitor the consistency and security of your container registry, that's the place where you keep all those container images before they even spawn. And then, of course, you have to have the overall visibility and unified reporting and compliance and everything else you'd typically expect from any kind of security solution. So again, there are so many different components in an ideal container security solution that I would say not very many security vendors actually offer a complete package. Some companies actually focus on specific areas and they do it exceptionally well while the others try to kind of be the object of all trades and do that reasonably well. And it's up to the end users to decide which approach they like better. And again, this is exactly what we cover in the Leadership Compass.
Right. So this as you described it, and as you said already, this is really a complex, a complicated matter, but this is only looking at containers, how does this integrate with overall cybersecurity infrastructures? Do these solutions that you looked at, do they have that in mind that they need to integrate as well into an overall cybersecurity architecture?
Well, I see there is actually more than one approach to this. Some companies will just say, okay, we have this decades long battle tested whatever security and vulnerability management solution. But we have adapted for containers by adding lists on these features and just kind of front exactly the same as you would do with your physical service or virtual machines or anything else. This is like the quote unquote old school, metal tested verified approach. Kind of boring, I would say. On the other end of the spectrum are the companies which basically sell you the quote unquote cloud Native Application Security Solutions. They would use this cloud workload label by saying, Okay, containers you would normally run in the cloud. What else can you run in the cloud? Server-less Lambda functions, for example, or just again, old school virtual machines. So we will give you a solution which actually covers all those workload types with our unified analytics. Again, which is something which many customers might prefer. But I would argue it's a fairly artificial limitation because the whole idea of containers is that you can run them anywhere, not just in a cloud, and most certainly you would want to run them in multiple clouds or even in a hybrid deployment. And when you are thinking about hybrid, you actually have to stop thinking in terms of cloud native and start again instead of connecting all the other existing types of infrastructure, network monitoring, API security, data protection. Ideally, all your cybersecurity tools have to work together in a kind of a cybersecurity fabric, if you will. A term which we talk a lot about in other podcasts and our materials. Yeah, but you cannot just buy container security as a standalone, isolated tool in a vacuum. It will never work.
Abbsolutely. And we cannot go into much technical detail. This just would go beyond the scope of this, and the length of these episodes that we do, did you identify specific highlights, when you did this research for the first time, what did you look at? What struck you? What was interesting to see in this market?
Well, first of all, as I mentioned, our approach is to try and cover at least the key features from all of those individual phases of the container lifecycle. So we were looking for solutions which have at least eight primary capabilities, which are container image security and container registry security, of course, to go up one layer of the actual orchestration platform security, the runtime monitoring, internet management, the auditing compliance and so on. Basically, we were looking at solutions which can do everything to at least a certain extent of ability and in total we have covered 20 vendors, I believe, almost 20, and I have to confess I was able to predict the top three eventual leaders in advance because it wasn't very difficult. And I could reveal that our top overall leaders in container security were RedHat, Palo Alto Networks and Aqua Security, all three of course well known and very well established and large companies, known for their security solutions. However, the rest, I found pretty interesting because there are some much smaller and younger startups which are delivering really innovative things in this area, with some machine learning based security analytics, sort of combining developer oriented observability with security telemetry and so on. So basically, you should not just focus on those three top leaders. If you're looking for the solution, which is best for you, you have to actually consider all the others as well.
Absolutely. I think that that actually is the role of the Leadership Compass. It is not looking at the right upper corner, which the the product to subscribe to or to license, but it's really mapping your requirements towards your criteria that you applied and to identify what is required for the individual end user organization or developer organization to find the right solution for them. It's not our analysts opinion, This is the best one, it's really helping users to find the right solution.
Absolutely. This is what has always been our goal. Our message is always to say, Stop looking at labels, start looking for specific capabilities that address your most burning risks and your most important problems. And if you are unsure what solutions actually can cover your risk or what questions you should be asking your vendor, talk to us, this is exactly what we do, we provide guidance and support in those decisions. So again, I would only recommend looking at our Leadership Compass, it should be already available on our website, kuppingercole.com. And again, if you have any open questions, don't hesitate to talk to me or to any of our colleagues.
Yeah, that really sums it up very nicely. So this is really an interesting document, a new market segment that we cover here. The Leadership Compass is out. So just head over to kuppingercole.com as Alexei said, use the search window and type in container security. And there you are. And in case you have any questions, just reach out to us or leave a comment below that video or just get in touch with us at any time that you want. Thank you, Alexei, for your time and for doing that interesting research. I will check it out, absolutely because I'm interested in how that works for this overall container infrastructure. Looking forward to seeing you in Berlin at our EIC and looking forward to having you at a future episode very soon. Thanks, Alexei.
Thank you Matthias, and good bye.
Hello Matthias, thanks for having me again.
Great to have you. And as I mentioned, I'm really looking forward to today's topic. You've just recently published a new research document, a Leadership Compass, comparing different vendors in a specific market segment. And this the reason why we want to talk about that overall market segment and why it's actually required, why do we have it. We want to talk about container security. Why do we want to secure containers and what are containers?
Yeah, that's actually the most important question, I guess. Why are containers suddenly so important? I mean, if you go back 10, 15 years, containers were basically just another form of virtualization, a handy tool for developers basically to be able to run the apps in different environments without worrying about misconfigurations or different network settings, for example, stuff like that. Basically containers gave us, finally gave us that long term promise, which started probably way back with Java. It lets you run your app once and then run it everywhere without modifications. Well, yes. If you are old enough to remember Java which was its original promise, which failed miserably. But then suddenly the alternative came with the containers. And now, for whatever reason, containers are just everywhere. Of course, people are talking about cloud native apps and microservices, which are usually powered by containers, but the same containers can be run anywhere. I have some containers running on my computer at this very moment. I have containers running on the Raspberry Pi in my home development environment. And again, this is the same container image which I can upload to a public cloud. And it will work fine, or almost fine without any modifications. And this is why containers are so easily embraced by developers and of course, DevOps teams around the world because they are so easy to manage, so easy to automate the whole lifecycle. You basically just need to run the script to create a new image which contains everything necessary to run your app, push it through your CI/CD pipeline, upload to your cloud environment, just run it, and then basically ensure that it runs stable and fast enough and to scale it up when necessary. Containers are almost perfect for running modern apps. And this is everywhere.
Right, and when we talk about containers and securing containers, what is included in this securing? You've mentioned, you fire them up with just a script and then you deploy them wherever you want to have them. Where does security come into play here?
Well, that's exactly, again, the same old problem we had with other breakthrough technologies, like, for example, restful APIs. But security doesn't actually come anywhere because nobody started the quote unquote container revolution with security in mind. They were only thinking about convenience and scalability and clouds and all the other fancy stuff. Unfortunately, the understanding that containers have to be secured came somewhat later and somewhat later still came the realization that the traditional security tools like firewalls and IDS or whatever anti-viruses don't work with containers very well. First of all, because containers are ephemeral as opposed to like virtual machines, for example, containers can pop up around for a few seconds and then just disappear because they're no longer needed or you might suddenly spawn 100 copies of the same container image and then you have suddenly to somehow bring all those hundreds or thousands of new containers into your management and security console, for example. So unfortunately, traditional security tools do not work well with containers because they lack awareness of all those issues. Another thing to consider, as I mentioned, the whole container life cycle is usually at least partially automated because it always involves several disconnected teams. You have developers who create the app, you have some DevOps or infrastructure people who actually set up the environment.
And then there is somewhere in between who actually has to build the image, push it into some storage registry and then spawn it later for the run time and stuff like that. These are all different teams, different teams using different tools, and the only integration buzz between them if you will, called continuous integration, CI/CD pipeline. Which again isn't actually, which was never designed with security in mind. So we end up with this whole idea that containers have a very long and complicated lifecycle with different stages and phases which are taken care of by different people and somehow you have to include security at every stage and then make all those tools work together. So container security is complicated. It's much more complicated than many people think. And this is exactly the focus of our Leadership Compass.
Right. So the security process starts with keeping track of which containers are where, at which point in time, and then maybe monitoring. What are key capabilities when it comes to looking at container security, what where the aspects that you looked at when looking at the actual products that are provided for maintaining container security?
Well, when we are talking about containers, we're usually talking about container orchestration platforms, most famous one being Kubernetes, for example. But of course, every cloud service provider had their own platform. And there are famous cloud neutral solutions, like, for example, OpenShift from RedHat. Those are platforms and those are really complicated solutions that have multiple layers which go all the way down to the bare metal hardware and then networking layer, some support services, databases and other types of infrastructure. The actual orchestration capabilities themselves, which take care of moving your new container to a certain host, for example, make sure that it's actually running. And if it's not running any more, then kind of killing it and spawning somewhere else, all those resource management and monitoring and analytics and access management, this is all built into the orchestration platform tool. And then of course, you have to secure the actual container images themselves, because what if someone makes a piece of malware into your container image how do you deal with that? And then, of course, you have to somehow monitor the consistency and security of your container registry, that's the place where you keep all those container images before they even spawn. And then, of course, you have to have the overall visibility and unified reporting and compliance and everything else you'd typically expect from any kind of security solution. So again, there are so many different components in an ideal container security solution that I would say not very many security vendors actually offer a complete package. Some companies actually focus on specific areas and they do it exceptionally well while the others try to kind of be the object of all trades and do that reasonably well. And it's up to the end users to decide which approach they like better. And again, this is exactly what we cover in the Leadership Compass.
Right. So this as you described it, and as you said already, this is really a complex, a complicated matter, but this is only looking at containers, how does this integrate with overall cybersecurity infrastructures? Do these solutions that you looked at, do they have that in mind that they need to integrate as well into an overall cybersecurity architecture?
Well, I see there is actually more than one approach to this. Some companies will just say, okay, we have this decades long battle tested whatever security and vulnerability management solution. But we have adapted for containers by adding lists on these features and just kind of front exactly the same as you would do with your physical service or virtual machines or anything else. This is like the quote unquote old school, metal tested verified approach. Kind of boring, I would say. On the other end of the spectrum are the companies which basically sell you the quote unquote cloud Native Application Security Solutions. They would use this cloud workload label by saying, Okay, containers you would normally run in the cloud. What else can you run in the cloud? Server-less Lambda functions, for example, or just again, old school virtual machines. So we will give you a solution which actually covers all those workload types with our unified analytics. Again, which is something which many customers might prefer. But I would argue it's a fairly artificial limitation because the whole idea of containers is that you can run them anywhere, not just in a cloud, and most certainly you would want to run them in multiple clouds or even in a hybrid deployment. And when you are thinking about hybrid, you actually have to stop thinking in terms of cloud native and start again instead of connecting all the other existing types of infrastructure, network monitoring, API security, data protection. Ideally, all your cybersecurity tools have to work together in a kind of a cybersecurity fabric, if you will. A term which we talk a lot about in other podcasts and our materials. Yeah, but you cannot just buy container security as a standalone, isolated tool in a vacuum. It will never work.
Abbsolutely. And we cannot go into much technical detail. This just would go beyond the scope of this, and the length of these episodes that we do, did you identify specific highlights, when you did this research for the first time, what did you look at? What struck you? What was interesting to see in this market?
Well, first of all, as I mentioned, our approach is to try and cover at least the key features from all of those individual phases of the container lifecycle. So we were looking for solutions which have at least eight primary capabilities, which are container image security and container registry security, of course, to go up one layer of the actual orchestration platform security, the runtime monitoring, internet management, the auditing compliance and so on. Basically, we were looking at solutions which can do everything to at least a certain extent of ability and in total we have covered 20 vendors, I believe, almost 20, and I have to confess I was able to predict the top three eventual leaders in advance because it wasn't very difficult. And I could reveal that our top overall leaders in container security were RedHat, Palo Alto Networks and Aqua Security, all three of course well known and very well established and large companies, known for their security solutions. However, the rest, I found pretty interesting because there are some much smaller and younger startups which are delivering really innovative things in this area, with some machine learning based security analytics, sort of combining developer oriented observability with security telemetry and so on. So basically, you should not just focus on those three top leaders. If you're looking for the solution, which is best for you, you have to actually consider all the others as well.
Absolutely. I think that that actually is the role of the Leadership Compass. It is not looking at the right upper corner, which the the product to subscribe to or to license, but it's really mapping your requirements towards your criteria that you applied and to identify what is required for the individual end user organization or developer organization to find the right solution for them. It's not our analysts opinion, This is the best one, it's really helping users to find the right solution.
Absolutely. This is what has always been our goal. Our message is always to say, Stop looking at labels, start looking for specific capabilities that address your most burning risks and your most important problems. And if you are unsure what solutions actually can cover your risk or what questions you should be asking your vendor, talk to us, this is exactly what we do, we provide guidance and support in those decisions. So again, I would only recommend looking at our Leadership Compass, it should be already available on our website, kuppingercole.com. And again, if you have any open questions, don't hesitate to talk to me or to any of our colleagues.
Yeah, that really sums it up very nicely. So this is really an interesting document, a new market segment that we cover here. The Leadership Compass is out. So just head over to kuppingercole.com as Alexei said, use the search window and type in container security. And there you are. And in case you have any questions, just reach out to us or leave a comment below that video or just get in touch with us at any time that you want. Thank you, Alexei, for your time and for doing that interesting research. I will check it out, absolutely because I'm interested in how that works for this overall container infrastructure. Looking forward to seeing you in Berlin at our EIC and looking forward to having you at a future episode very soon. Thanks, Alexei.
Thank you Matthias, and good bye.
Video Links
Stay Connected
Related Videos
How can we help you