Press Release
John Verry (00:00.238)
We’re recording it audio recording a video just you know, it’s streaming locally to your to your desktop So in the event that we see any pixelation or break up in sound it won’t happen in the podcast You know, it’s gonna go up on regular podcast it’s gonna go up on YouTube and then they’ll cut some clips out of it We’ll send those all to you see have all that so you can you can use it to whatever value it provides you the if you
shauli (00:11.959)
Yeah.
John Verry (00:28.186)
happened to screw something up really bad and you wanna roll it back, just say, hey, can I roll that back? They’ll cut it out later on. But generally speaking, my goal of this is to sound like a conversation between two moderately intelligent people. I’ll try to hold up my end. I know you can hold up your end, all right? Sounds cool. Shauli, did I say that right that time? Shauli, I’m gonna screw it up now. Now you got an admin.
shauli (00:46.126)
Fair enough.
shauli (00:50.967)
Just say, just say, show me.
John Verry (00:56.182)
Now you got my head. You shouldn’t have done that to me. All right. All right. So here we go. OK, I’m going to I’m going to record just a five second intro and then we’ll jump right into it. Right.
shauli (00:58.658)
It’s gonna be okay, don’t worry.
shauli (01:06.626)
Sounds good.
John Verry (01:08.402)
Hey there and welcome to yet another episode of the Virtual Seesaw Podcast. With you is always your host John Berry and with me today and now he’s in my head and I’ll mispronounce his name. You know it’s weird how sometimes you can’t you get a word in your head you can’t say it right. Shauli and it’s now I forgot your last name, Rosen. How are you this I was gonna say day fine day but it’s evening for you right?
shauli (01:24.332)
Yes.
shauli (01:34.474)
Yeah, same evening, you know, late afternoon.
John Verry (01:37.478)
uh… later where are you actually uh… you know you’re across the pond as we say aware where exactly are you
shauli (01:44.154)
Yeah. Tel Aviv, Israel.
John Verry (01:45.858)
I tell you Israel. Well, God bless all of the people that are dealing with this with what’s going on over there. Our thoughts here and prayers with all of you guys over there. So know that. Yep. Hoping for a quick and peaceful resolution as soon as possible. All right. So let’s get to something a little bit lighter. Tell us I always start easy. Tell us a little bit about who you are and what is it that you do every day.
shauli (01:57.896)
Amen to that.
shauli (02:12.65)
Well, so I’m CEO and co-founder of Armoo. I’m an engineer by profession.
I kind of like did many roles in engineering. In the past, I have some patents written to my name, but kind of like did my transition into business and strategy when I did my MBA in the United States in University of Pennsylvania, worked in a few consulting companies, came back to Israel, went back to startups until eventually, you know, finding one of my own together with my co-father Ben. And you know, today we are heads deep into Kubernetes security, you know,
customers. My day to day is you know usually calls you know another call with another prospect with another customer helping them solve things and get more secure.
John Verry (03:01.934)
Gotcha. So when you say UPenn, that’s Wharton you went to? Gotcha. Awesome school. Awesome school. And then one last question you said engineer, were you referring to like a software engineer? Were you referring to an electrical or mechanical or a more conventional engineer?
shauli (03:05.246)
Yes, that’s true.
shauli (03:19.242)
Yeah, I’m a software engineer. My major was around network protocols and those type of stuff.
John Verry (03:25.702)
It makes complete sense you landed where you did. I always ask before we get down to real business, what’s your drink of choice?
shauli (03:32.786)
Ooh, uh, ouzo. Um, if, I don’t know if you know what that is. Yeah, you know, it’s a… I’m Middle Eastern eventually, right? So it is what it is. Um, I really like it. I like the anise taste. And you know, I can go for any of those. Uh, Arak, sambuca, pastis, all feel kind of like the same for me.
John Verry (03:36.286)
Ooh, that’s the first time anyone’s answered Uzo.
John Verry (03:57.634)
Yeah, I actually like them as well. And my father-in-law is actually a big Uzo fan. And he prefers Uzo to Sambuca because of the lower sugar content, less sweetness. So it’s kind of the best of Sambuca without as much sugar. So I agree with you. I think Uzo is the better of the two. And Uzo is Greek, right?
shauli (04:07.468)
Luckily.
shauli (04:18.195)
Yes, Ouzo is Greek, pastis is French, I think. It’s very, very similar, but you feel more European if you drink pastis and not Ouzo.
John Verry (04:21.562)
I’ve never had that one.
John Verry (04:29.858)
So I feel a little more sophisticated when I drink that. But the other thing which is cool about asking for that one is no one’s ever heard of it. So you stand out immediately. Of course, we’re probably not going to have it anywhere now that I’ll start asking for it. So well, thank you for that unique answer. So I’m definitely excited to have you on today to talk about Kubernetes. And the reason is, in our role, helping organizations build provably secure and compliant organizations,
shauli (04:32.705)
Exactly, you know.
John Verry (04:58.126)
we see that there is definitively a little bit of a disconnect, a little bit of a challenge, right? For those organizations where they’ve got, you know, Dev, DevSecOps folks, right, working. And I’m gonna call it the more traditional compliance and security people. I think that most of us, myself absolutely included, are struggling to keep up with all of these changes and all the things that you guys are doing on your side of the fence, right? You know, the…
microservices architectures and containerization and CI CD pipelines and all this stuff, which is I can’t believe 10 years old or more, right? But, you know, seems really new and evolving to us. So I always like to kind of lay a foundation, right? So what is a container?
shauli (05:33.934)
Yes.
shauli (05:44.01)
So, you know, if you think about, you know, container is basically the evolution of virtualization, right? So, you know, if you think about, you know, container is basically the evolution of virtualization,
in the beginning, you know, you had a computer, then they say, hey, well, you can have a virtual computer, so you can run a few of those on one physical machine. And then they said, okay, but we can actually, you know, abstract it even further, and we can use one VM and one applications on it separately. You know, one of the biggest problems, or not biggest, but one of the problems of, you know, virtual machines, you know, still all of the different software running within it, kind of like could interact with each other.
and could get to the same resources, and there wasn’t enough separation. To be honest, containerization capabilities in Linux have existed way, way before Docker and before Kubernetes, but I think Docker made it, packaged it in a very good way, and that’s kind of like when it skyrocketed. So basically a container, think about it as a small computing unit, virtual computing unit that you can run software in,
It makes it very easy to deploy and to manage software because you manage small units instead of one big unit.
John Verry (07:04.026)
So I saw somebody say something once that I thought was interesting. I don’t know if you would agree with it. They said, VMs, conventional VMs, hypervisors, right? Are virtualizing at a machine or system level where containers are virtualizing at an application layer. Does that make sense? And is that a good way for folks like me that are not as intelligent in this stuff? Is that a good way to think about it? Or is there some flaws there?
shauli (07:33.546)
No, I think it’s a very good way to simply think about it. You know, if you think about, so I will say what you said, I will just rephrase it a little bit. Like if VMs are obstructing physical hardware, containers are obstructing.
operating systems. So, it lets multiple applications use the same underlying operating system without knowing about each other. That’s basically that. And I think that’s what that person that you are quoting referred to when he said, you know, application level.
John Verry (08:09.838)
I probably misquoted him by the way. So he’s probably out there mad at me right now going like, that idiot just totally screwed up my quote. So getting maybe a little bit more fundamental. What’s in a container?
shauli (08:28.782)
So a container is basically a packaged image or a packaged set of libraries and code that can run on a shared operating system together with other containers. So in my mind, the best way to simplify it is to say that every container holds an application.
It involves many processes, but one, in my mind, the container should be one functional unit that is running on top of an operating system.
John Verry (09:03.942)
Okay, so in that application, right, is it application code, is it the underlying VM, is it network infrastructure, is it firewall? Like when we think of the discrete components that are actually inside of that container, like what would they be like in old world analogs, right? Old development methodology analogs.
shauli (09:28.626)
Software libraries think about it as just a bunch of software libraries working together to create an app. So No kernel, you know, the kernel is shared. It’s not inside the container. It’s on the node Or on the VM that is running the container You know networking no like it uses the kernel networking Firewall firewall rules. No outside of that. It’s really
you know, lets the developer focus only on the application. Now, once the container is deployed, you need to configure all the other stuff around it. You know, what you enable it, what security you put on it. It has some security capabilities on a container level, but many of the, for example, configurations of how the container should run are defined outside of the container in a configuration file that lets the underlying infrastructure know what to enable and how to run the container.
John Verry (10:25.558)
OK, so if if. OK, so if I have a containerized application right that’s running in Kubernetes and that is going to ultimately run on a Linux virtual machine. Is that Linux virtual machine configured and implemented outside of the container or inside of the container?
shauli (10:26.386)
It’s a separation. Yeah.
shauli (10:37.463)
Yes.
shauli (10:44.606)
outside of the container. It exists there, it’s already running, and you can deploy a container on top of it.
John Verry (10:51.002)
Perfect, thank you. So we’re talking about this concept of containerized applications. Why are people moving to containerized applications? What are the benefits to the developers?
shauli (11:03.074)
So the main benefit, it’s an architectural change that you can make. So think about each software component or each application that you’re working on can be worked on independently and start to communicate with other applications and workloads via the network. And you can create much smaller applications, which today we call microservices. And this enables velocity.
and less dependency between teams when you think about velocity of development. Because you think about each team or developer is in charge of their own unit, and as long as they keep an interface consistent, right?
they can run independently of other developers and other teams. And as we scale teams and we get R&D becomes and engineering becomes a bigger and bigger division, basically working with a micro services based architecture is a much quicker way to develop. It’s more resilient because if one part of the code fails, it doesn’t mean that the entire application fails. And you probably hear more and more today
It feels like old news to me, but moving from monolith to microservices, it’s kind of like, it’s been a big buzz in the last 10 years and many, many companies are doing it more and more. And it’s mostly for scalability, better scalability, better operability and quicker development time and velocity of development.
John Verry (12:36.998)
Okay, so if you’re kind of thinking about old school development where you’d have different classes or different libraries that you know if you go on object oriented and you had things that did certain things. So instead of that all being packaged as a single application, authentication, authorization, whatever the processing is, whatever the storage is, whatever the interface to some other third party piece of software, each of those might be different in a microservices architecture and you can actually.
Develop the developers over here can work independent of these as long as we know what those interfaces are and they don’t violate the Protocol if you will for communication
shauli (13:12.054)
Yes, exactly. And then it has so many impacts to it other than working independently. Scalability, for example, right? Think about if you have one application that is doing both, I don’t know, taking inbound connections, doing processing on them, and then sending them to another class, as you said, in object-oriented that is working against the database, one might need to be scaled up and scaled down while the other one doesn’t, and you don’t wanna scale up the entire application.
are divided into mini applications, let’s call it that, or mini parts of the application, now you can have 10 instances of one of them running and two instances of the other. And you can still scale them up and down accordingly. And so it’s another benefit of the container, it’s just the ability to scale down and up based on just the velocity that it takes. So think about it, you need to scale up another VM.
heavy process. You need to scale up another container because it is a small unit it is much quicker to do.
John Verry (14:20.462)
Gotcha. Is the ultimate implementation of this that each of those microservices are running almost like serverless, like a Lambda kind of function, and they can be just like you said, just up and down, or am I going in a direction that doesn’t make sense?
shauli (14:35.222)
No, you are right. So, you know, there is a spectrum, right? There’s the monitor application that you update or put up and down once every year. There is the container, which is very easy to spin up and down and companies do it in a matter of, you know, every hour or every few minutes. And there are some containers that live for relatively long time. And some go up for like two or three minutes to do a job and exit. And then the lambda function is like the far,
or like the one with the least, I would say, lifespan, which you just go do a small functions and go out. So in my mind, Lambda functions are just an extreme. Containers are for more, you know, can be used for more stateful applications as well.
John Verry (15:24.41)
Gotcha. So how does containerizing an application in Kubernetes like change security? You know, from your perspective, is it harder? Is it simpler? And then from my perspective, I think part of the challenge that I have with it is it seems that security becomes more integral to the development process. You know, where an old school development, it was more discreet, more, more atomic. So talk about the security implications of containers.
shauli (15:51.082)
Yeah, so I would say the first and major implication of containers on security is not because of containers by themselves, is that because they drive.
a new way to build applications and they drive new architectures. And that is what I referred to before when I mentioned microservices-based architectures. So once you move from, you know…
a little number of big applications to a tremendous number of very small applications, networking, you know, becomes much more complex. Visibility of what is running and why it’s running becomes much more complex. Understanding the security risk and just because of the mere complexity of the architecture becomes more and more complex. And then, so that’s
I would say that the major drive for security complexity in containerized applications is merely the change in the architecture itself. Second of all, because those containers, so instead of now, instead of managing three big applications, now that’s why DevOps came into place, now as an organization, you need to manage, let’s say 500 different small applications.
you need to automate it, you need to make sure it is always running, you need to make sure everything gets the right resources, you need to be able to visual everything, and you need to be able to deploy it. And that’s why what used to be just operations become dev operations because the mere scale of it requires more automation. And…
shauli (17:43.362)
That also drives security to be a shared responsibility now between those DevOps and platform teams and security teams. Five years ago, security teams didn’t know anything, right? About containers and Kubernetes. Today, when I speak with companies, they have more and more dedicated Kubernetes security people. They have teams who work very closely with the DevOps. There is the famous DevSecOps title
more and more and security engineering and security architects get more and more knowledge of Kubernetes and vice versa. You know DevOps get much more involved in security, they care more about security. When we started I remember this saying everybody was saying well developers don’t care about security you know you can’t sell security to developers they don’t care about it and I always tell people that
developers and especially devops and platform teams, we see them super interested, super interested in security. They just don’t want traditional security. They want security that works for them, in their systems, in their environments. And we see more and more of that collaboration happening. And I think that’s a result eventually of what you said, of containerizing first and then Kubernetes and the complexity that is generated in these environments.
John Verry (19:08.922)
Gotcha. So how do you, you know, so when you talk about these new quote unquote, security issues, if we will, like if, if you’ve got the old monolithic application, right? All of the communication between the different layers happens within that one application where now what we’ve got this idea is we’ve got, like you said, 500 distributed microservices applications and the communication between them, I’m assuming is largely or all API based.
shauli (19:38.636)
Yes.
John Verry (19:40.178)
So is really the challenge, those APIs and those interfaces and visibility of that and ensuring that the construct and business logic associated with those APIs is well thought out, Greg, because we can scan for code-based vulnerabilities, right? Someone not denigrating memory or something of that nature, right, or someone using a.
a DLL or a common library that’s got a vulnerability in it. But so where are all those? Is it that interfacing and the business logic and the construct of those APIs that becomes the new challenge, if you will?
shauli (20:11.807)
Mm-hmm.
shauli (20:22.326)
Yes, but not only so So if you think about you know network policies, you know, you used to have like a few components Speaking with each other and you know you as a security architect you needed to say, okay This is the network policy that I want to apply to my organization
John Verry (20:24.185)
Okay.
shauli (20:43.33)
this, I know this application should speak with this application, but it shouldn’t speak with that application. So A can speak with B, but not C. Relatively easy. Now you have like 200 different applications and you need to
be able to understand who needs to speak with whom before you actually deploy the policy. And just writing the policy can be a pain. So there are different tools that will help you with that. But networking is just one part of it. Another part of it, like you mentioned, using a DLL or an object with a sort of vulnerability. When you add one monolith, that was one code basically, that…
many, many applications were running on top of it. So one DLL, one vulnerability was used by this monolith. Now you break this monolith to 100 different applications, right, and there are very small applications, but maybe half of them.
are still using or still, they still have that DLL. So now that vulnerability that you saw once in your environment, now you see it 100 times in your environment. Just because you duplicated that code so many times and you’re using it in so many places because eventually you know many, many of our applications, they use the same libraries. And that’s…
And that’s a big pain. And another pain is to understand whether or not, you know, now you duplicate those vulnerabilities, but do they have the same level of risk?
shauli (22:23.666)
in all of those different micro segmentations. So for example, you know, availability in one microservice that might be deep, deep in your environment and not reachable from the internet and doesn’t have access to any sensitive data, you might not care about it as availability, even the same vulnerability, but in a microservices that is open to the internet and has the keys to your system, for example.
So all of those complexities come into play as well once you start thinking about it in a microservices-based environment.
John Verry (22:50.566)
I never thought of that.
John Verry (22:59.586)
So it sounds like software composition analysis takes on an increasing level of import and I guess even just the concept of a digital SBOM as well, right? So would you have a digital SBOM per unit of code, right? I mean, like, or like how would you, that’s an interesting question, right? Because increasingly now, right, to work with the federal government, they’re gonna ask you for digital software bill materials, right, under NIST 800218.
If you’ve got a microservices architecture, like in an old monolithic application, right? You push the button, you get that, and you can hand it to them. When you’re doing that in a microservices architecture with, you said like 500 micro applications, do you have to kind of integrate all of those? Like how does that work?
shauli (23:43.014)
Yeah, so you just need to, you know, to maintain and manage many, many more S-bombs, right? Because you have so many more different applications and you have an S-bomb for each one of them. And yeah, it is just, it’s a bigger pain, but actually that’s not, in my mind, that’s not the biggest pain. In my mind, the biggest pain is to understand, you know, what is the, I would call it relevant or…
you know, impact.
John Verry (24:12.482)
Yep. Which ones are business critical and which ones aren’t, right? Because some of them, like you said, are not going to matter, right? If the encryption protocol is not as strong as we need it to be, and we’re transiting the internet, that’s a much bigger issue than if it’s transiting the internal cloud, right? Yeah, that’s pretty cool. I hadn’t really thought that through. All right. So obviously we’re getting to the next interesting question here. So, you know, we’ve talked a lot about security. You work for Armo. As I understand it, you guys created…
shauli (24:28.174)
Exactly.
John Verry (24:43.05)
And is it Cubescape? Am I saying that right? It’s not Cubescape. Okay, good. So, Cubescape, that is an open source Kubernetes security platform. So tell me a little bit about what that means. You know, what does, how does Cubescape work? And then we can start to drill into, you know, we’ve kind of painted a bunch of pictures of challenges. Maybe we can begin talking about how a product like that can be used to solve some of those challenges.
shauli (25:10.751)
Yeah.
So, you know, in the beginning of our conversation, you mentioned compliance in the past, you needed to run a scan and you did a very quick scan. So together with the complexity of Kubernetes, also compliance standards and tests that are dedicated to Kubernetes came up. And the way CubeScape came to life is actually because of that. The NSA and CISA, they came up with a hardening guidance,
guide to managing Kubernetes clusters and how to configure them in the correct way. And as you say, and as always with compliance, it’s like a very, very long list that if you as a security officer or as a DevOps engineer or security engineer, if you need to now go and test all of your environment against that hardening guidance, it’s a big pain. So…
CubeScape started very simply for numerizing all of the different tests that the hardening guidance is asking you to do, doing it for you and giving you a report of how you stand against that guidance. And that’s how we started.
And it got like superb traction. It got thousands of users and adopters. And we have like 100 contributors today. That we decided that we’re going to add more and more functionality into that. So as time went by, we added, you know, testing for all base access control within Kubernetes and testing for vulnerabilities and understanding which are the most exploitable and interesting vulnerabilities in your environment in Kubernetes.
shauli (26:53.2)
contributed Cubescape to the CNCF. It is today an official CNCF project. We are big believers of making it as powerful as possible and doing more and more, and we are always increasing the capabilities of it.
Today we have over one million different scans running every month using Cubescape as an open source. We have over 100,000 users using it in their clusters. And we are very, very proud of it. The idea of Armour was to build a control plane and to create more insights on top of this open source.
John Verry (27:34.374)
Okay, so my ignorance of Kubernetes will become pretty obvious here. So Kubernetes is a, like it feels to me like we use the terms a containerization system, like an application that manages containers versus the containers themselves. So I guess the first question I have is that when you’re running Cubescape, Cubescape.
I’ll get it right. Third time was a charm. Are we scanning the containerization system and the management plane and the way that’s all implemented? Or are we scanning the individual containers or are we doing both?
shauli (28:03.894)
Yes.
shauli (28:19.978)
Yes, so it’s a very good question and the answer is both. And the way we look at it is that Cubescape protects and scans, we call it security of Kubernetes and security in Kubernetes. So you are scanning everything that is running on Kubernetes but also the Kubernetes control plane and system itself.
John Verry (28:43.682)
Okay, so let’s talk about the Kubernetes container itself. Okay, so from a security compliance guy’s perspective, if you go back to old school, like you said, there’s sets of best practices, there’s CIS benchmarks, there’s NSA guidance, there’s vendor guidance on VM, Amazon’s got vendor guidance on securing a VM, a Linux VM. So.
Do we go into your, so if I’m a semi-knowledgeable DevOps CISO struggling with this stuff, and I wanna make sure I’m telling somebody what I want them to do, and if I’m saying, hey, I want this container to comply with the CIS guidance on Kubernetes, would that be what I would tell him, and then he would be using your tool to actually be able to do that, or maybe there’s different standards that you guys use, right?
Is that how that would work from my perspective as the CISO or my perspective as the compliance person?
shauli (29:43.606)
Yeah, that’s exactly how it works. If you think about honestly, the way we get most of our users, it is, you know, someone in the organization said, hey, we’re using Kubernetes. Are we compliant with the best practices of Kubernetes? And then someone will ask, well, which best practices are you referring to?
So they will Google and they will get that they do is the CIS best practices. They will see that, you know, SOC two requirements ask you to do a CIS benchmark, a scan of your clusters and then the DevOps will go and we’ll try to figure out what’s the best tool that will do it the best and the quickest for them. And that’s when they will, you know, come across a CubeScape, deploy it, you know, the,
I don’t want to sound promotional, but the biggest value of Cubescape is that people and DevOps can get started with it very, very quickly. They usually see results after like three minutes after they started to install it, and it fits very well into the way they like to work. That’s why they usually choose it.
John Verry (30:52.41)
At a baseline level, I think that a Kubernetes instance is a YAML file effectively, right? Or something similar, some type of markup language is what kubeScape is doing. I know. I’m just gonna call it your app from this point forward. So does it…
shauli (31:04.139)
Yes.
shauli (31:11.699)
CubeScape. I didn’t help you.
Yeah.
John Verry (31:19.126)
Is it just effectively reading the YAML file and knowing what it should see and what it shouldn’t see and then citing the places where it saw something that was not consistent with the requirement?
shauli (31:31.73)
Yes, and more. And I think that’s important because that’s the unique value. So I will give you a very, very simple example. Think about the configuration of, say, privilege escalation. Okay? You read the YAML and you see that this container is able, is configured, that it can do privilege escalation.
And that is for sure not the best practice and every compliance framework will tell you to minimize the ability to do privilege escalation.
But you as an engineer or a security engineer that is responsible for being compliant, you see that this workload or this container is configured to be able to do pure de-escalation. What do you do? Do you change it? Do you remove that capability?
you might kill the application if you do it. It might need it, you know, not everything that is not according to best practice is also a misconfiguration. So the value and the big value of ARMO is that we actually look at what your container is doing and we tell you whether it’s a risk.
but a risk that you need to take because the application is actually utilizing that capability versus no, it’s an overprivileged and you need to take it away. And that’s the biggest value that we believe we bring to our customers and users.
John Verry (33:03.654)
So real quick there, just to kind of make sure. So, KubeScape is open source, right? So I can download them, I can run that for free. Armo is a commercial product that is built, it provides extended value to KubeScape. And the feature that you just talked about was unique to Armo or is that part of KubeScape? Okay, cool. So that’s where we’re starting to talk about the value add of what you guys are doing on top of that.
shauli (33:21.102)
Yes.
shauli (33:26.742)
That was unique to Alvo.
shauli (33:32.994)
Yes.
John Verry (33:33.214)
One last question I have for you. So obviously deployed applications that are not secure are a problem. And we just talked about helping to manage that. I think you can argue that management plane problems are as bad or worse, right? Because if you’re not controlling the management plane, then you’re not controlling the containers underneath it. So talk a little bit about, so we have this component of Coupscape that does the…
scanning of the containers themselves. And then I’m assuming that you have another that looks at the configuration of the management plane and maybe you’ve got excessive privileges, maybe you don’t have segregation of function of duty, maybe you have too many people running in an admin mode. Talk a little bit about managing that risk, the management risk, which I think I’m amazed that people don’t think of that as being a risk more frequently or don’t realize how big a risk that is.
shauli (34:29.714)
Yeah, you know, people are not, so sometimes it is because they consider it infrastructure, right, so, and maybe it’s sometimes like different teams, like there is the application security teams, and there is the infrastructure teams, and sometimes, you know.
CISOs especially are very much like, you know, they many of them came from application security. And I think that’s a big driver to what you’re saying about disregarding the control plane. But when we work with our customers, and for example, we show them, we have this feature that there is a map of all of your control plane configuration and the role-based access control to it.
The main response that we’re getting is that people are amazed by, they didn’t even know, right? That they have that complexity. You know, you show them roles that they didn’t know they have, you show them configurations that they didn’t know they have. And I think the problem there is that people are just used to defaults, right? They deploy a container, they use the default, they deploy Kubernetes, they use the defaults and the defaults are…
really the biggest enemy of any secure system, right? Using the default is always, even in your iPhone or your Android, again, the defaults are what will catch you and what attackers will exploit. And I think that’s the biggest reason that people like, they think less about the infrastructure because they feel like it’s a given and it’s actually not.
John Verry (36:08.718)
Gotcha. So one last question with regards to visibility. So, so I know that Koopscape handles is looking at management plane. It’s looking at the Kubernetes instances themselves. Does it have visibility into, let’s say the VM that the application is running on or the, or the, or the Lambda like where does that line draw? Or do I need to actually look for those vulnerabilities and through other tools?
shauli (36:36.106)
Yeah, so CubeScape, the idea of CubeScape is to cover all of your posture and runtime security as long as you are within Kubernetes. So it will go from the VM that is provisioned into Kubernetes, which is called a worker node in Kubernetes terms, up until the application.
Now once something is running outside of Kubernetes, so let’s say you have Lambda functions in different places or cloud configuration aspects, that’s where Cubescape is no longer relevant.
John Verry (37:09.094)
OK, so you just said something and. Something which puzzles me a little bit like this. Before I asked you the question about what was in the container and we talked about that. The Linux VM is an example wasn’t in the container, but now we just talked about the fact that so is this just a semantics? Because I’ve heard people talk about that. The container addresses your VM, so is it so can you clarify that like so if I’m deploying?
shauli (37:23.703)
Yes.
John Verry (37:39.082)
a container, is it deploying or configuring those worker nodes the underlying components it needs? So while it’s not technically in the container, it’s still in that same piece of code that’s being executed.
shauli (37:55.79)
Okay, so it’s a little bit other way around. No, no, it’s a very legitimate question. So think about the VM, the VM, that’s the baseline. There is a VM running. It is running a Linux kernel, I don’t know, an Ubuntu, Red Hat, whatever it does. That’s, think about it as a computer that it’s running. Now containers are deployed on top of the VM.
John Verry (37:58.222)
And that might have been a terrible question that makes no sense.
John Verry (38:07.79)
Mm.
John Verry (38:23.342)
Mm-hmm.
shauli (38:25.138)
So you can run one container on top of the VM or 10 containers on top of the VM. They will share the operating system of the VM, but they will not know about each other. They will think it’s-
John Verry (38:35.482)
Okay, okay. I would actually go into it, like if we were talking about AWS, right? I’d actually be deploying EC2 instances of the Linux VM that I want, and then I would then be deploying Kubernetes on top of those particular, okay. Good, thank you for the clarification. Okay.
shauli (38:51.67)
Exactly. So for just kind of like small, like just to make it even clearer, because you mentioned EC2 and I think that’s a very good way to look at it. So think about it this way, you take 10 EC2s and you tell Kubernetes, you know, this is your underlying infrastructure. Now run those containers and they will take that container, repeat it on that EC2 and another container on another.
John Verry (39:14.287)
and it’ll figure all out for me, it’ll know how to scale, right, okay, gotcha. Very cool. All right, so it sounds, and I have one more question. Let me think of it, see if I can remember what we got off on tangent.
shauli (39:18.996)
Exactly.
John Verry (39:33.75)
It’ll probably come to me. So let’s talk about, so I think obviously if you’re running Kubernetes, you should be running KubeScape, right? I just don’t see why you wouldn’t. Why would I want to put Armo on top of KubeScape?
shauli (39:51.986)
Yeah, so if you think about Cubescape, Cubescape is, will work for you on one cluster, right? You will install it on your cluster and you can get access to all of the information and all of the vulnerabilities and misconfigurations of that cluster. Now, if you have, you know, 10 different clusters and 10 different environments, you would like a central location where you can visualize everything.
you can analyze everything, you can see the dashboards, that’s where the Armour platform comes in. So think about Cubescape as the agent that is running in the cluster. You can access all of that data on your own.
But if you have 10 clusters and you want to consolidate all that data to one SaaS platform, that’s where, you know, Armr comes into play. We take all the data from all of your clusters, we run, you know, algorithms on top of it, we show you what vulnerabilities are most relevant, we calculate attack patterns into your different clusters, and that smartness on top of the data that you can get as raw data from each one of the groupscapes in your organization is the added value of the Armr platform.
John Verry (41:03.226)
That’s cool. And just to be clear, a cluster is a single containerized system of individual Kubernetes instances, right? So I might have, like you said before, right? I’ve got 10 EC2 instances, a 10 EC2 instances, I deploy a certain finite number of clusters over here to do something over here, but I might have the same thing somewhere else, right? I might have five, you know, and if we go to like the…
microservices kind of architecture, right? I might, would I deploy my clusters per microservice? Would that be a typical way of doing that?
shauli (41:40.206)
Yeah, so that’s, you know, you’re referring to like a big question of, you know, whether you should use one large cluster or many small clusters. It’s a, you know, it’s a big debate. There are players here.
John Verry (41:53.87)
It’s a religious issue that I should, yeah. All right, I’m not going to go there, because I’m not going to have a conversation about DevOps and architectures for applications. I’m way over my head already, boss. All right, and I remembered my other question that I wanted to ask you. So is Cubescape and Arm-O, and the answer might be the same or different for the two products, are they just products that are used during build, the build process, or is there a runtime component to them?
shauli (42:00.11)
Thank you.
shauli (42:23.79)
There is a runtime component to both and the idea is to cover your security from development to production. And we are actually now coming up with even more functionality around runtime detection and response. So the idea is that Cubescape will cover your entire needs. So you will have one system that covers your entire needs with regards to Kubernetes.
John Verry (42:48.758)
Okay, so and just professionally curious, from a runtime perspective, is there some central log, if you will, of things that are occurring that you’re sitting on, so that way you can see an event and then basically compare that event against policy, if you will, and then say, hey, this thing happened, right? So if you look at like…
some of the cloud security posture management tools, right? You know, you can have a policy that says S3 buckets have to be secured, right? And if somebody spins it up, it sees it in that one log, I forget the name of the log, and hey, we got a problem. Are you kind of doing the same thing at the Kubernetes level?
shauli (43:26.282)
Yes, we’re doing it via the kube-api, the kube-cubinetis audit log, exactly.
John Verry (43:32.93)
Okay, so Kubernetes has an audit log that we’d be sitting on. Okay, that’s cool. All right, you’ve answered all my dumb questions, thank you. Anything we missed that we should talk about?
shauli (43:48.63)
No, Kubernetes is of course is a big thing. No, I think there’s so much we could have talked about, like the adoption of Kubernetes and when will security become more and more important for… Yes. Yeah.
John Verry (44:05.326)
Well, I’ll ask you a question about the adoption, because I saw a number that made no sense to me. So when I was preparing for this podcast, I was like, all right, I got to smarten up a little bit, not embarrass myself. So, and I saw a number that they said in 2022, 60% of organizations had deployed Kubernetes. And that made no sense to me. And the reason it made no sense to me is, I don’t think 60% of organizations do development. So is that 60% of organizations that are doing development are using Kubernetes, or 60% of all organizations? Because…
Half the organizations in the world, companies in the world don’t do anything with software.
shauli (44:37.95)
Yeah, so it’s definitely out of those who are using, who are doing development and.
And out of those, another nuance is whether or not that 60% is in production versus they are trying it in different places in the organization. So in 2022, I would say that a majority of them were still testing it around. 2023, in my mind, was the year that Kubernetes went into production. And we saw it because we saw more and more security concerns come to your mind once you start using something in production, right?
We saw that rise during 2023. And we believe it will become even more prevalent in 2024.
John Verry (45:19.438)
Yeah, we have a fair number of SaaS’s that are clients of ours, and I think the vast majority of them are actually using Kubernetes. I mean, I guess once you hit a certain scale as a SaaS provider, Kubernetes just makes too much sense to people.
shauli (45:38.526)
Yeah, exactly. And if you start a company today and you’re a SaaS company, you know, I want to say 100%. 99% is that you’re gonna base your infrastructure on Kubernetes because it is just becoming the standard.
John Verry (45:54.726)
Plus, I would assume that if you were starting a company and you were trying to attract good software engineers and you tried to explain anything, I mean, everybody wants to work like software engineers are famous to want to work with the latest language, with the latest technology, right? So if you were trying to pitch a monolithic application with a waterfall-based SDLC, I’m assuming there’s not going to be a long line of people waiting to interview for that position.
shauli (46:06.766)
Yes.
shauli (46:18.542)
Thanks, guys.
John Verry (46:20.314)
Alright, this has been awesome. So I sent you this late, so if you didn’t think about this question, we’ll cut it. Give me a real world or fictional character you think would make an amazing or horrible see-saw or if you prefer a DevSecOps lead.
shauli (46:35.094)
Hmm
shauli (46:39.99)
Wow, that’s a very good question.
shauli (46:45.39)
I would say, you know, I’m thinking, you know, and I don’t know how to name the character, but I’m thinking about a character that has like, like an octopus. Like, I’m thinking about the villain, there is a villain in Spider-Man who is like an octopus. No one knows what he’s called. Yeah, I don’t know his name.
John Verry (47:03.929)
I don’t know his name either. We’re losing all the Marvel comic… I think Spider-Man is Marvel, right? I’m not even… I’m not much of a… All right, sorry. So I think we’re losing the whole Marvel part of our audience, which in technology has got to be pretty high. We just lost them because we don’t know the name of a Spider-Man character. All right, so why would he be terrible?
shauli (47:11.882)
Yes, I think.
shauli (47:20.905)
Yeah, I like it.
Well, because it will be very good, not terrible, I’m sorry. Because Justy has so many arms, I think, you know, we’ll be able to manage all of the different things in the air. That’s kind of like what I’m thinking about, because every CSO or DevOps guy I’m speaking with, they’re mostly overwhelmed with the number of things they need to manage simultaneously. So kind of like that’s the image that I’m getting in my head.
John Verry (47:27.127)
Oh, he’d be good, okay. Why would he be good?
John Verry (47:32.941)
I’m sorry.
John Verry (47:46.298)
Alright, so, because he could have an arm for every piece of his microservice architecture. So why didn’t you go like Millipede or Centipede then, right? Because they’ve got hundreds or thousands of arms, right? I mean, they’d be even better. But there are no characters, I mean, there are no Marvel characters that are Centipede man. Maybe, maybe, maybe. Alright, well that’s actually a good one, I like that. Alright, so.
shauli (47:49.322)
Yeah, it’s not fair.
shauli (47:56.054)
Yeah. So… Yes?
shauli (48:03.226)
Exactly. It’s a matter of the image that popped up to my head.
John Verry (48:14.354)
How can if somebody wants to talk about cubescape or armor? How would they get in touch with you?
shauli (48:21.93)
Yeah, the easiest way is armorsac.io, our website. Or you know, anyone, you know, I’m always happy to chat on LinkedIn, Shauli Rosen. Unique enough name that not many of us exist out there, so you’ll be able to catch me.
John Verry (48:37.206)
Excellent. This has been Fun Man. Thank you.
shauli (48:39.618)
Cheers, really appreciate it and I really enjoyed it.
John Verry (48:42.614)
Hold on a second. Let me hit stop.
