It seems like incidents of Kubernetes cluster attacks keep hitting the headline. Can you tell the viewers what the attack landscape looks like at the moment?

It's more about running malicious code, crypto miners, etcetera, etcetera, all of the data from a cluster. Miro, what do you think about it?

Yes. So, in Apple, we have a lot of honeypots, right, spread across the Internet, and and those honeypots are waiting to be attacked.

They are running on Kubernetes that we have a lot of workloads and applications.

And what we are seeing is that the majority of the attacks are still crypto miners. Right? People are or attackers are getting inside of the those honeypots and they're they're running their crypto miner, campaigns.

This probably eighty percent of the attacks are around that.

I think that, generally speaking, attackers wanna do the same thing however they can. So if they want to install crypto miners in the cloud, they also want to install crypto miners on Kubernetes clusters. And the more cluster that are that are in the world, the more crypto miners attack the Kubernetes cluster.

Kubernetes is uncharted territory where security is concerned because it is complex and it is relatively new. Can you talk about what the gap is between a legacy environment and a Kubernetes environment?

I can I can say legacy environment? It's still active environments for many companies who that who did not adopt the Kubernetes environment. So, another point was to compare that as Kubernetes, it is more about API driving the operations instead of, deployment or call to operations.

And that is make, like, some challenges for security team to track what is going on in the cluster, who and what's running, and then it's it may be around for five minutes and disappear from the cluster.

And then how to track all of these, changes that is all, like, challengeable task for the whole team.

Yeah. Sure. So so when, looking at, Kubernetes security versus legacy, you know, few things that may maybe to mention. One, when you look at Kubernetes, you you actually look at two layers. Right? You have the infrastructure layer, which is the Kubernetes itself.

Kubernetes is something like forty five different services, you know, daemon sets, pods, persistent volumes. All of them have have different ways of configurations.

So so you have, like, a metrics of forty five services with the amount of configurations that each one can have. This is one thing, you know, configuration issues in the infrastructure level.

And not to mention that there are about one hundred different types of distributions for Kubernetes. Right? And each one has its own tweaks.

So complexity, right, of the infrastructure, that that's a big deal. How do you secure that?

After you handle the complexity of the infrastructure, now you also need to handle the application level.

You have applications running on Kubernetes, your MongoDB, your NGINX, your Elastic. You know, they are running on Kubernetes similar to to how they are running on the regular infrastructure.

And this is where you need to protect the application, making sure that the application doesn't have vulnerabilities, misconfiguration, you know, zero day attacks.

Right? So all in all, when you think about Kubernetes security, you need to make sure that you have a good handle on the infrastructure itself. And maybe we will talk later how do you how you do that.

And then and then a good handle on the applications running on Kubernetes Kubernetes itself. What makes things even more complex is, as Andrew said, the entire environment is dynamic. Right? There is a lot of infrastructure as code compared to the legacy systems where, you know, everything was static. You had to sign a re sign a request to set up a a server and then sign a request to set up an application.

With Kubernetes, an infrastructure is coded.

It's very fast and dynamic. You just run Terraform. You click enter, and then you have a Kubernetes cluster. You have applications run running on top of it. And now you have the challenge of how do I secure it. Right? And I'm I'm pretty sure that we are going to touch upon how to secure it in a minute.

You can look at Kubernetes as basically another cloud platform.

And as Amir said, it's not one. It's actually many flavors of a cloud platform because it has its own workload. It's all configuration. It's all identity. It's all networking.

So all of the complexities of cloud of solutions for it's probably called legacy cloud platforms, not legacy cloud platforms.

You need to duplicate everything to Kubernetes with the challenges that were mentioned before. The challenges of the cloud dials up to eleven.

Cloud is is dynamic. Kubernetes is more dynamic. The cloud is configured as code. Kubernetes is only configured as code.

So I think it basically takes the changes of protecting cloud but makes it much harder.

We covered this in parts, but, what are the crit critical vulnerabilities that put the Kubernetes environments at risk? In that, what are some of the common attack vectors that cyber criminals are seen exploiting to target Kubernetes clusters?

As we mentioned, Kubernetes is all configuration as a code. And, like, first of all, it's that is, misconfigured Kubernetes API that is exposed publicly. Everybody can connect to it. I I will not mention Tesla company with a public dashboard that is supposed to, like, mostly disaster for them. They're just one of the example of a misconfigured Kubernetes API. Amir, would you like to share something?

Yeah. Totally agree. I think the the number one issues issue in Kubernetes vulnerabilities is actually misconfigurations.

Right? You have so many services.

Each service has so many ways to configure, and, you know, people make mistakes.

Right? And a mistake can be you're provisioning an application with other permissive permissions. Right? This application has too much access, to the level that it can actually administrate, Kubernetes, and you don't even know. You you just choose some default role and deploy application with that default role and suddenly this application, you know, can be leveraged into some nasty attacks, right, through the application.

So by all means, what we see is that the number one issue is is misconfigurations.

On top of misconfigurations, there are the regular open source vulnerabilities. You know, Kubernetes by itself is open source. So, you know, it has its own vulnerabilities at the infrastructure level.

Just last week, I think there were, like, something like a dozen of vulnerabilities specific to to Kubernetes.

But not only vulnerabilities are specific to the infrastructure in Kubernetes. You you also see vulnerabilities open source vulnerabilities that are at the application level. You know, those containers that are running on Kubernetes, I mentioned Nginx, Mongo, Elastic. You know, they all have regular vulnerabilities regardless of of Kubernetes.

But due to the fact that those applications are are running on Kubernetes, suddenly, the combination of, misconfigurations of Kubernetes of the permissive pods and vulnerabilities on the application level, that toxic combination suddenly becomes, much more impactful for attackers.

I I totally agree with, Amir and Andrew, and I want to add that Kubernetes, architecture the most common architecture of Kubernetes is microservices, architecture, which is much more API heavy.

So a lot of APIs are exposed in many cases because of misconfigurations.

So and they're not supposed to be exposed to the intent, but they are.

And, vulnerable APIs can lead to exploitation of many vulnerabilities.

And after the, the, let's say, pod is exploited, the sometimes you only run things with the pod and you run a cryptomide or whatever, but it's not so be a first first step to a a more a deeper attack. You can go from there to the cluster or to the to the node itself.

And, again, many times, what we see now in environment because of misconfigurations, the nodes are overprivileged.

So here, I I said that Kubernetes is a cloud in in on itself, but it's also a part of a cloud most most, most of the times. So the node can have strong privileges, like, high privileges for other things in the cloud and can be used to, exploit.

We have some questions and comments coming in from the viewers. One of our guests is asking, do we miss the days of submitting request to set up a server and then another request for the app?

Yeah. Actually, don't miss the days. You know, I was a developer in my history, and I remember that, you know, as part of a dev team, when I wanted you know, I finished my work, the code was ready, and now I had to wait weeks, sometimes even months, before I had this code running in production, have to file Excel sheets in order to ask for, you know, ports to be opened in the firewall. It was slow. Right? Things were much slower, maybe better from a security perspective. But, for developers, it was very, very slow.

It was simpler also.

Ah, I I I think it was sorry.

I definitely don't miss, this time, but, it's one of the reason why we have this approval sent, etcetera, etcetera.

Because, like, developers are lazy in terms of checking permission, checking boundaries of the application, and, like, developers would like to run it today or yesterday because everybody pushing developers to run it, run it, run it.

And then, like, okay. Let's give my service account admin permissions that I don't want to, give a grain access to to my port because I do not want to check what is will be broken or, what will be failed, what permission exactly I need to give, like, minimum permission to support. Again, I will give you, permission, like, the full broad permission to to run-in my application.

And then it's lead to the one of the vector of attack. And that is I definitely I do not miss time when it's, better permissive and I have to have to fill a lot of papers, but I definitely now I'm more wise and I will work with my service account with my permissions application by myself.

I think it touches on a evergreen topic of, for security teams, the of how to be enablers enablers for innovation or how I call it, how not to be hated by developers.

So, I think the key is to have this to keep having guardrails, but have them lightweight enough and fast enough and automated enough so they don't have any innovation. And if they have innovation, they just get bypassed.

So if, as a security team, you want to have guardrails, it must be fast and, almost seamless.

And as we know that there has been a profusion of cloud native applications in recent times, how do you think that has contributed to the increase of Kubernetes related, attacks?

So I think the most simple, answer is that the more, cloud native applications, the more Kubernetes clusters, the more attack surface.

And the more attack surface, the more it's targeted by attackers because it's worth the time and effort It brings them money.

So I think I think that's in that, it's as simple as that.

It's this dynamic, this complexity bring a lot of headache for the security teams, like, to manage it.

May maybe another reason that I can think of, why attackers are, you know, where Kubernetes is becoming, their favorite victim is, when you think about an attack, it has multiple stages. Right? You have the way that an attacker will get into the application, whether it's a misconfiguration or or just a vulnerability.

So assume that, now you have an attacker accessing, let's say, an NGINX for a vulnerability.

The next step, because this NGINX is hosted on a Kubernetes cluster, suddenly, you have more options. You can do container escape. Right? So you can leverage a vulnerability in the kernel and, you know, get out of, the container into the host.

You can leverage misconfiguration of Kubernetes and and try and find over over permissive, pod, access that pod, and and try to run another Kubernetes pod in the environment and start, you know, doing a lateral movement.

You can leverage the fact that you might have an IIM role assigned to this pod and and now try and access, you know, cloud services.

So the fact that, someone was able to get into an application running on Kubernetes many times because of those toxic combinations, misconfigurations of the permissive pods gives more capabilities into lateral movement and data exfiltration.

We have another question from one of our viewers.

Why would anyone expose control points, Kubernetes, and databases to open traffic? Yes.

Henry?

It's a great question.

The short answer because developers want to change want to run the code on the system and, like, to make changes to Kubernetes that is just connect to the API and to, like, load to your manifest. And then developer, oh, I have to learn a new tool. It's so nice and it's not boring, etcetera, etcetera. And that is one of the reason why it's exposed because it's the of the simplicity and how easy, like, developers can work. But in this case, it's open a lot of a lot of vulnerabilities.

So I think that in short, there's no good reason. I mean, there's a reason why every decent Synap or Kubernetes security product will alert on such configurations because you shouldn't.

But as Andrew said, there are a lot of things you shouldn't do, but you do.

And, because of knowledge gaps and because of laziness and because you must fix things fast. You you do sometimes you do what you have to do even though it's not good practice.

Yeah. Just to finish on that, I don't know what's the reasons people do mistakes, but I can tell you that if you go to show them show them, you know, it's a website that maps the Internet.

As we speak, you you will probably see, you know, tens of thousands of Kubernetes open to the Internet.

You know, they are just out there.

Amos, my question to you would be why are traditional security policies and practices failing to protect Kubernetes environments?

I think a significant, part of the the reason is that in Kubernetes, everything is as code. You have infrastructure as code for the cloud, but in Kubernetes, it's everywhere. Everything is as code. You have the manifest of Helm Chow, so or whatever.

And you need to to to be able to to protect it because of the life cycle of the, development from the infrastructure as code, the m encode and definitions, all all of that. And you need to protect it during deploy using admission controller, and you need to protect it, continuously see whether it has the right security posture, and you need to also have runtime protection.

So you need to protect it through throughout all the all the application life cycle.

And it's, it's different than, life it's kind of different from the life cycle of applications that don't have Kubernetes. The way you do it is different is, different than the way you do it for standard cloud applications.

My understanding is that complexity is the, key theme here. What role does automation play in securing the integrity of Kubernetes environments, and to what extent can it ensure security for Kubernetes?

Yeah. Yeah. I I think that, you know, when you look at Kubernetes and the application life cycle, it's all about automation. Right? You have developers writing code, pushing a button, and then a few minutes later, now you have the code running in production if all goes well.

And you don't have any other option than to automate security. Right? You cannot secure something using manual work if the application life cycle is automated.

So so what do you do? Right?

I think in Kubernetes, you have, some gates that you can integrate into the application life cycle. And in those gates, this is your opportunity to automate security.

So let's quickly go over those gates.

So gate number one, developer pushing code into the SCM system, whether it's a GitHub, GridLab, Bitbucket.

Here, you have an opportunity to scan the code that developer have have pushed, either scan it for vulnerabilities or scan it for misconfigurations. Right? And there are many tools, including open source tools, very good ones that that you can leverage in order to do the automated scanning of vulnerabilities at this stage.

Mhmm. The second stage is, what Andrew mentioned is admission controller. So you have now an artifact ready to be deployed in production.

A minute before it's deployed, Kubernetes provide you with a mechanism called admission controller where you can write some automation to check whether the application that that's gonna run-in a minute has the sufficient security configurations.

Right? So so, again, a lot of open source tools, commercial products that will do admission controller. They will check whether the application that's gonna run-in a minute is has sufficient security.

And then the the the next stage is gonna be runtime protection.

You have an application running in your production.

This application might have still might have misconfigurations because maybe you missed it. It's it might have vulnerabilities because there are new vulnerabilities, you know, every every day.

So you want to have runtime protection monitoring the application that it's running, identifying, misbehavior, and then, you know, of course, blocking, that, misbehavior from happening.

Amos?

Yeah. I I totally agree with what they they said before. I think, we gave a great overview of the automation you can put in the process, during the application life cycle.

We have another question from one of our viewers. Says, securing Kubernetes starts with securing, bare metal VMs or PAS or managed service installations before going into application security. Can you please share your knowledge on this?

Yeah. So I I think, it's it depends.

Obviously, the cloud security, the general cloud security, not the Kubernetes security, in many cases, is responsible for securing these layers.

And in the cloud, we have the shared shared responsibility model. So in some cases, who's responsible for, securing these layers is the cloud provider itself.

For example, if you, if you use, managed Kubernetes like, EKS, you don't need to secure the machines themselves because the because AWS takes, responsibility for it.

So I don't think it's part of the Kubernetes security solution per se, but I I agree it it should be a part of the holistic solution. But the responsibility for for it really depends on your, specific use case and the specific deployment method you use.

I would like to add, you may build in cloud, like, a special with the AKS, like any cloud provider. You may build in a secure setup.

For example, allow remote access to the Kubernetes nodes with the SSH. Sometimes it it it's just an option. Like, by default, it's turned off, but you might turn it on, and then my key will set up, like, insecure.

But I agree with Sam as there is, like, barometer or anything like cloud provider instances, etcetera etcetera. It's like, it's our responsibility with a cloud provider.

And from, user standpoint, it's like limit access to Kubernetes nodes.

It's, do not put them into the public network. It always must be in the private network.

And, like, that is if it's in the private network, it's probably secure enough. If you if you isolate any access to these machines, then it's, you you you don't have it. That's it. Then, like, your next your next best on it will be Kubernetes and to running containers. Like, if you'll prevent running containers in the privilege mode, then probably nobody will has access to the Kubernetes instance nodes.

And that is like and then, like, all responsibility for this, like, securing these machines will be on the cloud provider.

Yeah. May maybe one thing to add, you know, at the end of the day, Kubernetes is running on an operating system. Right? Whether it's Red Hat, DBN, Ubuntu, this operating system is using kernel. This kernel might have vulnerabilities.

So I do agree that although Kubernetes gives an obstruction of the underlying operating system and bare metal, but you still need to harden those.

You still need to make sure, Andrew, as you said, that no one will, have SSH access, right, to the host. You still need You know, scan for vulnerabilities on the operating system level. You need we still need to patch them because although it's abstracted and you don't see it in in many times in the cloud environment, you don't even own it.

But, if if you are, you know, if you are using, something like an OpenShift or an on prem Kubernetes, you do own the the host itself, and and you will need to patch and harden it.

So to sum it up, Amir, would you say it's shift left or shift right? One of our viewers is asking.

It's actually one of our logo, taglines, shift left and shift right. We do both. But I think at the end of the day, it's both.

You need to shift left because you actually have an opportunity to do security, as early as development cycles. So like I said, the developer is pushing code into the SCM system. You have a huge opportunity here to make sure that this code has the right security practices.

But only in doing that is not enough. Right? Next day, there will be a new vulnerability.

Next day, there will be a new misconfiguration, so you also need to shield. Right?

Andrew, would you like to add to that?

I would like to add that this, we definitely should harden our container.

One of our viewers says, if someone touches a running container, it needs to be destroyed and programmatically replaced. Do you agree, Amos?

If someone touches a running container?

Mhmm.

Yeah. I I think, one of the challenges but also, benefits of Kubernetes is everything is is ephemeral.

You need to understand how it was touched. How did they get there? And if you don't fix the root cause, it will be touched again, will be compromised again. And so you need to, to investigate, find out the vulnerabilities or the misconfiguration or whatever that allowed attackers to get there. And you should obviously kill the container because it should be stateless. It should be able to restart quickly and, you want to clean, clean slate. So you should.

Let's talk about some best practices that companies can adopt to secure, Kubernetes workloads and containerized applications. And how can organizations implement effective continuous monitoring, continuous protection for the environments?

You must take into account that you can't limit everything.

You can't always go all the way. There's a trade between security and speed. That that's almost right. And Axiom, almost always true. You you try to limit to to make it better, but it's it's almost always true. And you need to to manage this this, trade off. Many good practices implemented, but you need to bear in mind that developers will need to keep working and fast because you want your business to run fast.

For developers, that is a huge mindset.

It just introduce a new way how applications should be developed, how applications should be configured.

And one of the, like, security points that is, cloud containers and code. And it start, like, secure code starting from the code. And when you create the flexible code that you can debug, monitor, and run-in the security environment, then it's not a challenge for developers. And in my opinion, the the biggest challenge for developers, that is the mind shifted to the new way how to write the code.

One tip that I can add on top of, Andrew and Amos, you know, traditionally, when dealing with security, it's very important to define boundary boundaries.

So, you know, whether physical, logical, in the case of Kubernetes and containers, it's very hard to do physical boundaries.

So, my suggestion is, to define logical boundaries, whether those boundaries are based on Kubernetes namespace, or they can be based on labels.

There are many ways of defining those boundaries.

And then what what you do, you set up your security and posture management based on those boundaries. So I'll give an example.

So many times we see that, you can define network security rules within a namespace, meaning a container cannot access other networks that are out of bound of the same namespace that this container is running under.

The same you can do with permissions. You can assign roles that are only assigned per namespace, and two namespaces do not get the same role and so on and so forth. So, basically, choosing your boundaries and then managing your security based on those boundaries, this is something that I've seen that helps securing at scale.

Andrew, and lastly, how can enterprises adapt and adjust their Kubernetes security strategies against evolving threats and really future proof their, security strategies?

Yeah. So, I think one of the most important thing is to have to embrace Synapse as as an approach and to have a trusted security vendor because their job is to to follow the emerging threats and to find solutions and to find to to help you monitor for, emerging threats and to to solve them and to fix, issues. So if you have a vendor you trust, they can take you to the future and, follow the trends for you and take you take you with them. Another thing is very important for the present and for the future is to invest in trading.

There's a serious, knowledge gap in Kubernetes, in security teams.

And, so trading is a must, and Mhmm. Trading is not a one time thing. It's an ongoing thing. You meet security personnel and must have time to to follow the new trends and to to read and to, understand what what's going on.

One thing from my side is and this is a question I'm I'm constantly being asked. If you could only have one one control, one security control, that you can choose to secure your Kubernetes, environment, what would that con control be?

And and, you know, let me help you with how I think about it. So, you know, let's say, okay. Maybe let's try and tackle vulnerabilities of open source libraries.

But then if I do that, then maybe I will miss misconfigurations, which is, you know, as bad as vulnerabilities.

So so maybe not that. I'm not I'm not choosing that. If I will choose the misconfigurations, then I'm going to miss vulnerabilities. So, okay, maybe I I'm not going to to choose that one control.

And finally, when you think about it more and more, you figure that run time. Right? At the end of the day, if you have a very, mature and, run time capabilities that can identify malicious activities and block them from happening, that would be my one control that I'm choosing. Because at the end of the day, you know, it will all boil down into you have an attacker now getting access to your environment. And if you can identify that access being made and if you can block that from happening, that's probably your one control that, you know, can can, you know, prevent, against the vulnerabilities, against the misconfigurations, against the lack of knowledge that I must mention.

That would be my one one control.

Let let's agree to disagree.

I don't believe in the silver bullet. If I have to choose one, that is, education part because there's no silver bullet to all all our problems with the Kubernetes.

I think also that, it may be an interesting thought experiment. Like, what is the single guardrail you need to have, or what is the single solution you must deploy?

But in reality, security a good security is layered.

It's always a combination of many, many different layers of guardrails that we mentioned before. So, you need all of it, basically. That that's the harsh, truth.

Runtime is important. Code is important. Posture is important. You need to have all of them, and the more you have, the more secure you are.

Related to that, we have another question that is, is there any zero trust with Kubernetes?

Yeah. Kubernetes comes out of the box with network security. Right? So depending on the network provider that you have, some of them also implements the the network security capabilities.

Like I said, best practice is to do, network security segmentation based on a namespace.

Mhmm.

So that way, pods running on the same namespace would be able to communicate with each other, but if they would try to communicate with another namespace, it would be blocked.

And also, some of the runtime Kubernetes security vendors also provide, you know, zero trust capabilities to Kubernetes.

And one last question. How well would you handle supply chain with Kubernetes?

Supply chain with Kubernetes, it's not about Kubernetes itself.

Security rules. That is what kind of vulnerabilities allow it in the cluster or is there, like, zero critical or zero major or zero minor vulnerabilities? Then, like, developers or people who create new containers should care about, oh, okay. I just created container from Ubuntu's version sixteen. That has got a lot of vulnerabilities inside the container.

And that was, like, system just block creating this image and put in our Thank you, gentlemen, for talking to me, and thank you everyone for watching.

With that, I'll turn it over to Ziv.

I would like to thank all of our speakers for taking the time to join us. Looking forward to seeing you all again. Have a great day.