Cloud Native Computing Foundation Kubernetes Community Day Czech Slovak 2022, 10 May 2022

Previous Meeting

⏯

youtube image

►

From YouTube: 27 04 pro Leonid Sandler Kubernetes Zero Trust Security

Description

KCD 2022 CZ & SK virtual - Prvá CNCF cloud native konferencia v regióne Čiech a Slovenska. kcd.live

A

You will hear everything you need to know about kubernetes posture management and runtime protection, ways to secure your software supply chain, managing attack, surface reduction and how to secure kubernetes with zero trust. Please welcome mr leonid okay.

B

So again, good morning, everybody and uh thank you for spending your time on kubernetes security. My name is leonid and next hour. I will talk to you about what is zero trust, specifically in kubernetes world, how to achieve it.

B

Probably will help you with some practical advices of how to handle it in your environment. uh Please feel free to ask the questions I'll try to run very fast for the presentation, so we have enough time at the end, to talk about uh specific issues and questions that you may have during this time.

B

So uh before we go to zero trust itself, I'd like to get us on the same page with regard to what are we up against? Why are we doing this?

B

uh What attackers are looking for in in in the environments that we are protecting and how they get in and what they do when they, when they get in okay, so first of all uh data is, is probably the primary suspect, but it's not the only one they're looking for keys, they're, looking for secrets, they're looking for resources like coin miners is very popular uh attack, vector today to steal your cpu and some other resources. uh They sometimes they look for uh damage and extortion. Type of things and ransomware is also very financially motivated or.

A

B

Be looking for intellectual property that you uh have in your system, some unique algorithms, some unique apis that you might have somebody wants to use everything is of value now. If I take many different ways of how they actually break in how they can compromise our systems, I can boil them down into three kind of macro groups.

B

One of them is misconfiguration. You forget to configure something or you misconfigured, something that will be found and utilized there's a lot of tools in the internet today that will find unprotected bucket or or unprotected interface or some sort of uh potential. uh You know web.

C

B

Can you still hear me.

B

Can you hear me.

B

Is somebody there.

B

Just wanna see everybody on mute. Okay. uh I assume you can still hear me.

B

So uh the other way is the credential abuse, whether it's uh insider, malicious inside they're, incompetent inside the unfortunate insider or just credentials that were, incidentally, lost somewhere and they would use them to break into the system. We'll talk about what exactly they'll do when they do it when they get there and the last but not least, probably the biggest and the most problematic one. Is software vulnerability exploits the amount.

A

Of vulnerabilities.

B

Exploitable vulnerabilities is growing by the minute and you can see in the cve type of sites how many popular products have critical vulnerabilities vulnerabilities with remote code, execution, etc. It's.

A

Not necessarily.

B

By the way, in the container image that you are executing, it could be in kubernetes itself, it could be an operating system, it could be spread across different components, and you really really need to understand how attacker utilizes them and go from one action to another to actually get the whole picture done.

B

Okay and after they get to our system most likely, they will either abuse some existing software they'll figure out what bucket was not protected and just go there and get the data from it.

B

They could change the behavior of existing software by, for example, changing configuration, changing environment variables, parameters, etc, or, of course, they may inject a new software either by corrupting or compromising the one that you already have inside or by um adding new software components to your system. Okay, again, it doesn't matter which way they get to that point. They can use compromised credentials to run another pod in a kubernetes cluster or they may utilize software vulnerability and and rce to inject some malicious executable into the into the cluster. Okay.

B

This picture is important because we'll get back to it. When we talk about uh protection techniques, okay, so what is zero trust, and why does it help us or how does it help us? So, first of all, I want to say the zero trust is not the destination is rather a journey. It gets you one step closer. Every action you take gets you one step closer to the promised land, but unfortunately, that promised land keeps going farther and farther away, because we always have new vulnerabilities.

B

We always have new attack vectors attackers are very clever, they evolve every day and therefore we need to evolve the protection layers every day.

B

A zero trust is a concept. It says. Never trust always verify sounds nice. It was invented over 20 years ago, but verify what or trust what. What trust, what not to trust, how we can verify it. When should we verify it and the last but not least, is why now, during this presentation, we'll talk about what we have to do and how and when etc in much more details? But at this point I want to uh just spend one minute to talk about why.

B

Why do I even need to know why? I'm verifying uh a privileged container or exposed interface. Why is that important to me? You know people who run antivirus say. I know I need to run antivirus, that's it. I know I need to do it. Do I need to understand every virus for that?

B

Probably not, but when it comes to kubernetes- uh and you start to you to assess your kubernetes security posture you'll be using what what they call uh security validation frameworks like cis like late camera and sage, we we're in armor like very much and I'll, explain why, in a second uh those frameworks, they'll tell you what to check some of them have over 100 different checks and you need to basically go over them one by one.

B

Do you need to understand why you're doing this? Well, in my opinion? Yes, you must understand why you're doing this, because after you run this like cis framework, you'll get tens or many tens of failed controls if you're lucky, you may have much more by the way, and you have to realize or understand what what do you do now, all these failed controls how they affect your own environment, how they affect your own business model. What do you need to fix? First? What do you need to fix later?

B

This is why you need to understand why, okay and now, of course, let's go and talk about what we check etc and the first step to do a first step to realize how protection scheme works in general.

B

Is I always like to talk about this 4c model, which was proposed by google also several years ago, which which is a cloud cluster container code? Well, who cares they kind of missed the name space, but it probably didn't fit right with the four c's. So, uh let's, let's look at this model and see what what is uh kind of contributed or miscontributed by every layer of this model. Okay, we use cloud uh to configure our cluster okay.

B

We use cloud to get base images for our nodes and everything that uh is coming from the cloud provider or data center provider or the image that we took from uh some repository for that purpose. Okay, it uh has to be properly configured, it has to be timely, updated it has to be um basically uh monitored all the time throughout the entire execution session.

B

So cloud part is very important. However, uh there are tools like cloud cloud security, posture management like cspms, which understand the existence of kubernetes inside, but unfortunately, kubernetes in the cloud is kind of a blind spot for those tools, because there's a collection of different uh worker nodes and uh a control plane. The control plane sometimes come from the cloud service provider, so they have a visibility of it and probably do pretty good job in updating and configuring it. But uh still there are certain things that you need to make sure.

B

Okay, you need to make sure that audit log is enabled you need to make sure that uh anonymous authentication is disabled, ecd is encrypted, etc and that that is kind of a boundary between cloud and the cluster. But once you get to the cluster, the cspm cloud view is basically becoming kind of blind, because you have many nodes and.

A

B

Those nodes may be something different at any moment in time. You don't really know what kubernetes is going to put where what is going to decide to um run on this particular machine and therefore uh understanding a security of kubernetes itself, even though it runs within broader cloud. Environment is very, very important, and it's probably even uh isolated from the cloud, a broader cloud picture, because some people only use kubernetes or use majority of their application in kubernetes and therefore much.

A

More important.

B

For them to understand what is the security situation of their kubernetes cluster, okay, so in cluster level, we see uh many different controls that we need to look at, like our bug, like uh role-based access control like uh whether we have anonymous authentication or not, whether we have a proper communication between our cubelets and our cube, api server, etc, etc.

B

Cluster configuration is very important. Do we properly use namespaces or not? Do we even need to use namespaces or not? Is our cluster multi-tenant or not, and then we'll look at cluster roles versus namespace roles differently? If our cluster is not multi-tenant, we'll care less about it, if our cluster is multi-tenant, we'll care much more about it, okay and every step we take towards better posture gets us one step closer to to the promised land.

B

C

Container layer is.

B

Is interesting and different, because container layer is kind of two-fold okay, sometimes we from kubernetes standpoint we configure container execution parameters, we say well that is container runs as privileged or not we say, with it's container runs as root or not what privileges it runs with, what capabilities it run with, etc, etc, whether it has access to node or node, node network or not, etc.

B

But this is what kubernetes can impose on the container. The other side of the container is what software developer put in there. Sometimes software developers put or make certain assumptions about how containers going to run and use those assumptions in a way that kubernetes controls are incapable of changing them. So, for example, if your software in the container uh sets up a root access root ownership of certain file, then kubernetes cannot change, run as root to something else, because container will just simply not work.

B

Okay- and there are many examples like this. Therefore, uh it's important to understand when we take a lot of containers from third parties. I I don't want to use term public repository, because sometimes you use private repository, but still my sequel, container or kafka container in there is is basically the same as you can get from any other public repository. So we take it from the third party and we have to understand what they do.

B

We have to understand how to configure them and how to reduce the attack surface, but we have to realize that sometimes we cannot go all the way and basically do everything we want, because uh the code that runs inside the container will uh will will just stop working now when you scan container for vulnerabilities, if it's a publicly known and and wide widely known uh application like nginx or some java, whatever you'll find a lot of vulnerabilities in it, because people are looking at it and reporting those vulnerabilities.

B

If it's your own application, you'll probably find nothing in there. People who experience with running containers will also know when you run many of uh contemporary pieces of code which have developed in, go and use what they call. The gold flat images- you won't see practically any vulnerabilities in there unless a certain version of go compiler was known for certain vulnerability and.

C

This is why? Because.

B

A compiler basically compounds everything into one piece, it's very difficult to tell which framework you used or which library you use, and therefore, then the amount of known vulnerabilities in that code will be zero, but.

A

It does not mean that you have zero vulnerabilities.

B

In there it means that they're just unknown or sometimes called like zero day. Okay, so uh the security of kubernetes and security in kubernetes. There are two different viewpoints that you need to realize: maybe it's technically a technical realization, maybe it's even organizational. Sometimes security of kubernetes is carried out by certain team like infrastructure, team and security of in kubernetes is basically more taking care of the application team. Sometimes.

C

B

There's no there's no rules about this okay, but it's important to see the distinction, so uh we have our misconfigurations. We have uh credential abuse, we have sort of vulnerabilities exploit and, let's see the road, let's see where it takes us.

B

You've heard the term security is shifting left many times, probably. Well, I rather like to say: security is extending left because shifting it means that left leaves something behind ah security has to start as early as possible. There's no question about it, and this is why we need to look at what we. What do we do we develop? Let's see, what can we do when we develop?

B

Let's see what can we figure out from security, wise right upon or during development cycle, so that we don't wait until our container gets to the production and then gets bumped back, because it violates some some rules that our uh cso has set up. Okay uh and we'll talk about what tools and what checks we can do it all of these stages we deploy, we have to figure out what we deploy and where do we deploy in dev cluster or do we deploy in prod cluster? How do we distinguish between these clusters?

B

Sometimes people run a lot of validations in the dev cluster, which is pretty much wide open and and then, when the product or application gets to the probe, it gets bumped out again because there are much more strict rules in production. So we need to understand the distinction between these environments, but these distinctions are not uh always um unnecessary.

B

Sometimes you really need to have broader access to your dev environment. So you really need to understand what is the necessary difference between dev and pro then try to minimize it and then once you deployed well, the game is only starting because if you have vulnerabilities in your code or you potentially lose your credentials or expose your credentials, things will happen during the execution.

B

Nobody exploits vulnerability when software does not run it happens when it runs, and so it's not enough to say, we've launched a healthy container or container that we thought was healthy. It's not enough to say we have checked our vulnerabilities right after ci cd. Two months ago, new vulnerabilities came up. We need to monitor continuously and understand what happens inside the cluster. During the entire execution session, okay, so let's, let's take it like step by step.

B

Okay, the first uh and probably the most obvious step- would be what we call the posture scanning. That step verifies your kind of static or pre-deployment status of your application.

B

You have uh excessive or unused roles in your arbuck, for example, and again I'm going with the same template like what when and how which we've uh mentioned earlier in in in the discussion.

B

Okay, uh do you have uh containers that run run as root or privileged containers, privileged containers in even more dangerous than runners root, because they disable all the underlying uh security profiles like, for example, sec, comp and capabilities etc?

B

Do you have access to your node resources or your host uh file system or network? uh Have you configured your uh you know, file system as immutable? uh Are you allowed to access cube api or not all of these verifications? Okay, and, of course, have you scanned your vulnerabilities? Do you have lost secrets and etc, etc? Network policies, so you basically check the status of your configuration as a lot of different checks. A lot of different controls and you'll get many results. Some of them will succeed, some of them will fail.

B

Some of your containers must run as root. There's no way to avoid this. How do you treat this so? First of all, you need to do it as early as possible. Then.

A

B

Time and more understanding you also sit closer to developers, sometimes see so that look at the cluster cannot understand whether a container must run as route or not. You have to go and find appropriate developer that released this task three months ago and doesn't even remember what was there. So it's it's important to understand to start early in development and therefore you need to choose tools that can run in your development that can run in your staging even before you get to production.

B

Okay, you can check your repositories. You can check your container registries, don't necessarily have to have cluster to verify many of these things, but, of course, when it comes to a production, you have to continuously repeat continuously check those things over and over again, as I said before, new vulnerabilities come out. You have to figure out how to address them. You have to catch them in time. Three months ago, when you released that container image that vulnerability wasn't there now it is, you have to address it.

B

Okay and therefore again, you need to choose tools that can run in all these different uh areas of uh uh of your development and and deployment cycle. Okay and you, you may use the posture scanners, you may use some uh arbuck visualization and analysis tools. uh Sometimes it's admission controllers, we'll talk about them in a second okay. That tells you what roles you are not using. For example, okay, uh you can use container scanning. You can use it's very popular now to have plugins or extensions to uh visual studio code.

B

We've done some survey a couple of months ago. It appears that over 70 percent of people use visual studio code to edit their to to create and work on their yaml files and and that that is very fortunate, because uh the extensions may not not just us. Many people uh publish extensions to visual studio code uh which allow you to do verifications very, very early in the process. This is very important.

B

Admission control admission control happens when, basically, when your workload is launched or when certain command in your cluster is executed. So if you want to do cube, ctl exec and your admission control is configured properly. It will pass through that mission control and you have to understand whether you allow this or not again, not every admission control. Give you all these capabilities all these flexibilities, but this this is the way to look at okay, or this is the way to to aim uh mission.

B

Control always happens in the cluster, so we basically need cluster for that it still could be dev, cluster or broadcluster.

B

uh My personal recommendation would be to have admission control in both and and just configure them they usually have to work, can work in alert mode or or deny mode, and I in our in our environments we always configure admission controller in dev cluster in a load and then in production cluster in deny, and therefore we can basically see what's what's ahead of us.

B

uh Admission controllers can uh basically understand user behavior patterns. This.

A

B

Are very important if some user works nine to six okay, and that still happens. um You know in just just monday to friday, okay and suddenly he comes in on saturday.

B

Probably we should consider this as a potential break-in or potential abuse of his credentials. uh You may, if you look at the arbuck from from uh cloud vendors. You'll, have a lot of roles, a lot of uh uh basically user or group names that that are not used in your environment. It's very important to understand and remove.

C

B

You don't need to.

C

B

Anything that is unused in the system, another.

A

Personal recommendation.

B

I would give you is never ever use cluster admin for your daily operations in in my clusters. In my environment, cluster admin will be rejected. If clustered mean comes and say create code, it will be rejected.

B

We don't do this, because cluster admin is very dangerous role and cluster admin by the way is not just a role that called cluster admin. There is a hard coded, meaning in kubernetes to all that called clustered mean, but any other role that has a star in in verb or or in resource or or in binding. Okay will basically uh consider in our system at least, will be considered as a cluster of mineral, regardless of the name and- and my point is that these roles should not be used in uh in a daily operation.

B

They only need to be used when you manage your cluster. When you do something you create other roles, everything else has to be very, very specific and targeted to the people to the job that people need to do. Some roles are bound to name space kubernetes provides that capability and it's important to use it, especially in the multi-tenant clusters. Some roles are cluster-wide again, if you don't have multi-tenancy in the cluster. You can be more easy on this, but if you do you don't need to use cluster-wide rules for practically anything in the daily operations.

B

Okay, um the other thing uh or the other kind of kind of group of checks that admission controllers give. You is all these posture validations. All of these checks that we've discussed before now becomes a policy not just diagnostic. Somebody will tell you you run this port is privileged in admission controller. You can say no privilege, pods, don't start in my system, okay and you can block it now. Obviously there are exceptions. Therefore, if you uh run postures continuously and every day you get this notification, that's a specific engine.

B

Export runs as privileged and you need to to run it as privileged. You can set up exception and normally, if the product is uh is decent, then you'll get the exception. One place and they'll be also helping you in the other. You won't have to configure exceptions in 10 different places, but it's important.

A

B

Configure the system towards your needs. This is why you need to understand why. Okay, every kind of misconfiguration has a meaning and it's more uh valuable. If you understand how that translates to your specific environment, okay, you can uh limit uh containers that didn't pass for vulnerability scanning uh you can, for example, if you have pci dss regulation, then you have a critical vulnerability that lasts more than 30 days in your environment, that known to you more than 30 days. You have to stop that container from going up.

B

Okay- and these are the rules that you can basically set in the admission controller and every such rule will give you one step closer to the promised line, uh and then, of course, we come to the runtime okay, the first thing before we even get to runtime specific issues. Okay, it's important to understand that a lot of configuration parameters in your cluster are not visible. On the declaration layer, your yamls.

A

B

What they need to declare towards kubernetes to make kubernetes work, you'll see, for example, if you install elasticsearch lake, you will see the service for the master nodes, because somebody in cluster need to talk to them, but you will not see anything related to in inside the lake communication. Basically, those are familiar with the configuration the 9200 port.

A

B

Declared in the kubernetes layer.

A

Not only because it's not necessary.

B

But also, sometimes the way kubernetes works with services may be uh potentially harmful to multi-node, distributed systems like elastic or or cassandra or similar.

B

Okay, and so uh it is important to get this to know this, even though it's not declared in kubernetes layer for people who try to uh protect their environment, they have to know every port that is open, whether it's declared in kubernetes or not, and runtime kind of visibility, life visibility of what really happens inside the containers during the execution is very important part that enriches your poor understanding of your posture, okay and then, of course, usual suspects. Like network policy enforcement.

B

Okay, you have to set network policies because you you want to limit potential spread of of malicious software. We'll talk about this in a second and see what the meaning of this okay, um you, you figure out what executable uh modules are actually going up and you can set up some some some sort of allow deny control list on that. Okay, you need to have some tools for this. It's not something that's provided by kubernetes, but more of most.

C

B

The kubernetes security products uh would give you that capability, okay, uh a privileged execution tracking privilege, escalation tracking, sorry file, integrity management, software, identity, validation, we'll talk about this in a minute in much more details, it's very important subject: okay, software configuration validation. Remember we said our software may be misconfigured. That would be enough to compromise the environment, okay, some behavioral type of adr, xdr, etc and, of course, figuring out. Whether your second profile is is up to what your application really needs.

B

It's closed enough or not again, runtime happens in the cluster, but still can be development, cluster or production cluster. So we have to distinguish between them and you, you have kubernetes native security controls that you can use, for example, for network policy. You may use some more um flexible and more kind of secure products like istio service, mesh or others. Okay. These are not the only ones, but these are pretty well known ones.

B

You may have uh like demon set agents that usually provided by uh security platforms like like cubescape like aqua, like uh bridge crew, etcetera. uh You have uh audit log analysis you. Basically, if you configured audit log properly, then now you get information that you can run through and see. What happens in your cluster is somebody trying to do something that he was not allowed to do. Somebody tries to create both gets denied. Okay, it didn't cause any damage, but you better know.

C

B

Is happening you better know that somebody is trying to do something in your cluster that was denied, because that somebody is either either poor worker that cannot do his job or uh somebody inappropriate that try to do damage okay and things like uh detection response, like adr or xt so say we did.

A

All that, okay in.

B

Every single step, as I said, took us one step closer to what we need to achieve in the uh and the zero trust environment. Now we have.

C

Less workloads.

B

Running as privileged, so they can cause less damage. We have network policy. That means that a spread can go in certain way and cannot go in in other way, say we have all that and we have a lot of sources of the information. How do we deal with this? How do we treat it and literally, if you run frameworks like cis or or nsa, whatever you'll get tens, if not hundreds of uh different uh workloads in your cluster that failed? It's all not.

A

B

An function of number of controls in a framework it also a function of number of uh workloads or pods in your cluster. Basically, the context is is very important if I have critical vulnerability in my container image, it's bad. If I have critical vulnerability in my container image that is configured to communicate with the outside world is worse.

B

If that container is configured to run as privileged is really disaster, and that context is very, very important.

B

This is why I would recommend you to consider the tools that you are going to use, because, yes, you can have a cis scanner which works standalone and you know what is your cas diagnosis, okay and then you can take a stand-alone admission controller that that will give you certain policy or ability to define certain policies, but only white platforms that understand all of these angles, or most of these angles will allow you to actually combine all this information and say I've got this from my image scanning. I've got this from my posture scanning.

B

I've done this from my cluster configuration. This is what my runtime told me: where is the risk? What I'm doing tomorrow morning, when I come to the office to fix my system to make it better, you can close a lot of unprivileged containers and that may not actually improve your posture because you close them in the places that were not really dangerous in the first place.

B

Okay, so context is very very important and contextual.

A

B

Is is very, very important, so say: we've done all that have we finished or not.

A

B

Is definitely we didn't and- and I want to talk about elephant in the room, because it's it's very, very important to understand. We've scanned our images, we've defined, we've minimized or completely removed, number of images that runs is privileged or root. We.

A

B

Access, we have no service account that allows us to talk to kubernetes. We have network policy as good as we can get it. Okay, we have network.

C

Anomaly, detection.

B

Tools which is even more powerful, we don't have any unused secrets. We don't have any unused volumes. Okay, we have to figure, and why are we doing all that? That's the most important question why we did all that? What are we afraid of my sequel runs as root, so what it will not do, any damage running is rude.

B

Okay, I have a service account that that is mapped. To my I don't know, uh kafka or.

A

Or some secret.

B

Unused secret that mapped to kafka, so what it will not use it, it's not designed to do it, it's not configured to do it. Why would I care- and the answer is always all of these things- we do because we're afraid of compromised software.

B

If my software gets compromised, then those things become dangerous before that they are not dangerous. This is why I said if you have privileged containers somewhere in the basement that doesn't communicate with anyone, doesn't have any access to some sensitive information. It's privileged wow leave. It figure about figure out where the more more dangerous place is and fix that everything.

A

B

And, and the key point is that compromise.

C

B

Is the one that causes the most of the headache and most of the potential pain?

B

So we can minimize all these attack angles and still leave with potentially compromised software with zero-day attacks or with uh known vulnerabilities that get exploited in five minutes by the attacker and takes us about 20 days to in average industry today to actually update them. Okay, some some people take much more I've, seen customers who are running uh linux, images that went out of support window over a year ago, so you can imagine how old they are and how dangerous is that.

B

So there are several ways to deal with the compromised software, but look at what what software does? Okay, when software runs its application or some service? What it does is basically free things. It executes an.

A

Algorithm that was designed.

B

A

B

Files that read some secrets as a sensitive file example, and it calls others calls interfaces and- and you can basically take a very complicated system and break it down into the pieces like this. This is kind of a uh atomic unit like a molecular of the the software architecture. Okay- and the question is who is.

C

Calling my apis.

B

Who is reading my data? Do I really know who is doing that? Is that a legitimate software, or is it a compromise software?

B

I don't really care whether it's compromised by broken uh or uh of use credentials or it's compromised because of exploited vulnerability. What I care about is this software legitimate or not.

B

This is very, very important part to understand. After we've configured our posture set up our admission controller.

A

B

Our system, what do we see? Do we see this or not? Okay and unfortunately, the technology.

A

B

Yet at the point where you can continuously verify that your software is legitimate well,.

C

B

Was there until recently, so here uh uh the model, the armor, zero trust model that uh I kind of wanted to to to present you, okay, we've built a system where uh basically, a new technology that allows us to continuously verify cryptographic, integrity of every piece of software that runs inside your containers and, as I said before, that's what we worry about.

B

We worry about our software being not compromised, not compromised as a code not compromised as a configuration, okay and- and- and this is what this uh we call- this- a software dna technology which basically maps all the executables all the script files, all the configuration files, environment, variables, command line parameters for every process that starts in your pod and pod is is very complicated entity. It has multiple containers. Each container may have multiple processes.

B

A

B

A very very heavy mapping task, but at the end of the day, all of these artifacts are snap snapshot, snapshot and signed cryptographically and continuously verified during the execution. The verification during the execution is the key here because, as I said before, the vulnerabilities are exploited, while the software runs and being able to know at every moment in time that your software is not compromised.

B

Gives you a lot of assurance that your entire system, even if sometimes not always configured, probably pro properly either, because you missed it or because you couldn't do it better? The runtime protection of software identity will give you another layer or another, a line of defense that is additional to what you have and it's very, very powerful.

B

Now the way we can use that line of defense is also uh very important. What what we can basically do with this is to make sure that only workloads that are signed and verified are healthy and authorized can communicate with one another.

B

The only workloads then can there are signs and healthy can access data in files using uh transparent data encryption, and that is what we call the true zero trust model, because now, at every moment in time you you know that you're, not only talking to my sequel, you know that you're talking to healthy bicycle and it's mutual, that my sequel knows that you are healthy. He knows who you are knows that you are not compromised throughout your entire execution session. This is why we call it the true zero trust, and this is continuous.

B

Okay. Now this does not replace your activities with the posture, it's very important to do every step in the way to do it right, because, obviously, every improvement that we made on the posture, every improvement that we made on that mission and every improvement that we made on monitoring, makes us one step closer, and this is a final or last line of defense if you wish, uh which gives you even better assurance.

B

Okay- and this is very much aligned with the concept of zero trust because, as they say, don't just verify so you can always verify now. Remember this one: okay, why did I just make the distinction between reading the files and accessing the apis? Well, because files are dormant, they don't talk to you, you just read them. They have no way of saying no.

B

When you access the interface interface is, is a active entity, you can, it can authenticate you, it can require you to to actually do something while just reading the files is, is much more difficult to protect, and this is why we do it with with the encryption. Basically, encrypt files, transparent encryption means that application doesn't need to know that it's been done like uh in a similar concept to a site car, whether applications speak tcp and the site car turns it to tls.

B

We we've kind of developed the same concept for uh file access and therefore only if application is authorized to decrypt that file, it will get it uh properly, otherwise it will still get it encrypted now. This is the example of uh I took a snapshot from the real customer. Okay, it's pretty big customer about 300, different workloads in one namespace and the reason.

A

B

Is because you know good luck, defining network policies with that, not only because there are many connections there, but also because imagine that there is a company that develops such a big system. What is the change velocity every day, many different workloads are changing in the system. Every time new communication line comes up and and goes out, and you not only need to enable the new one. You also need to disable the old one.

B

How exactly are you going to do this you're going to have completely a separate system where there's no security, so you can figure out who now talks to whom this is very, very difficult. This is why this model, the basic zero trust model, is, is such a efficient, because you say: okay.

B

If, if, if workload a is not supposed to talk to talk to workload b, it won't do it in order for it for it in order for attacker to actually trigger that, they need to compromise the workload identity, and this is why protection of identity gives you much better coverage, much better assurance that, even before it gets to do something bad.

B

We already know this workload is bad, so basically look at this as uh trying to figure out um whether what workload is good or bad based on what it does versus based on what it is. This model checks based on what it is, and it's much easier, much faster, much more deterministic and much less false positives. If signature of executable file or script file is wrong, it's wrong, there's! No, it cannot be incidental, it's very, very important and- and I think it's this is where the future zero trust is.

B

Okay. The other example I wanted to give you is, is example of kubernetes secret life cycle, okay, uh and- and what I wanted to say here, is that the the secret uh uh life cycle goes way beyond kubernetes boundaries. The secret gets created and before it gets to, kubernetes has to be somewhere in the yaml files in the script, files has to be backed up somewhere.

B

It has to go to some git or other software repository only after a while, it will be loaded to kubernetes secrets, okay and we'll see it in etcd, either clear or globally encrypted. It doesn't bring too much security. Unfortunately, okay and when the workload starts, it will be mapped to a temporary file to that application and throughout this entire cycle, this this secret is unprotected.

B

So if you do it in in a backup and and other systems, you have to have another protection system to actually do it, not just the kubernetes one, but also pre-kubernetes one.

B

So the way that our file include file or secret encryption works is that secret gets encrypted, basically right after it's created, and then you can put it anywhere because it's already encrypted it gets encrypted. In this uh you know, repositories and backups and everywhere it's protected. There's no worry about it when it's loaded to kubernetes it's also already encrypted, and you define the permissions based on this workload, identity that we have discussed rather than on the name of uh of a a portal container, and then, when it's mapped to a temporary file, it remains encrypted.

B

A

B

Valid application, valid and verified application reads that file that secret gets decreed.

B

So it basically gives you a very convenient way of dealing with secret, because kubernetes secrets is very convenient and very much aligned with the rest of the things that you do in your product, mattis environment. But it also.

C

B

You a protection which is completely transparent for your applications,.

B

That's it for today. Thank you very much and I'll be happy to answer.

C

Questions, if you haven't.

C

Could you elaborate how the network policies are created automatically.

B

uh Yes, okay, uh there are two ways to create network policy. There are several ways to enforce network policies. First, one way is to use kubernetes native network policy mechanism, which basically allows you to say which workload can talk to which workload on the ip base or or kubernetes label base. The slight problem with this approach is uh one.

C

B

For as long as you stay within the cluster, and you can basically treat workloads by their labels that their their attributes, uh it's pretty good, but uh when, when you start talking to outside of your cluster, then you, you basically hit the problem, and if you define kubernetes network policy, especially the egress one, you have to say exactly who you want to talk to. Sometimes, when you communicate with platform services, it's very, very difficult to define.

B

This is why I would normally recommend to use ingress policies, it's much easier to define much easier to figure out who talks to me. Okay, especially within the cluster and and therefore you can use the selectors. We can use basically a label of a workload that can communicate with you.

B

Okay, uh the automatic way of creation of such policy is usually based on uh gathering the actual communication information. So basically, as you saw the graph that we build for uh the communication between the workloads, we then take this graph. We see who talks to whom and we automatically generate uh ingress policies for for those who receive the calls from within the cluster the the other way, the other, the one. The other way that I mentioned was using uh armor, uh true, zero trust.

B

Technology is basically built on the fact that we can protect the identity of the workload rather than actual policy. The policy is there, the all the communication is tls, but the policy says whoever is healthy and authorized to communicate in general.

B

Can talk to me now if a can talk to b, but shouldn't should talk to b or should not talk to c as long as a still healthy, it will never even try to talk to c to make it talk to c you need to compromise it and and before you actually get to talk to c you'll compromise the identity.

B

So we'll know this is unhealthy workload and therefore it will prevent it from talking, and this this way it's a very, very easy way to define a communication policy both in in in a completely automatic way.

B

That makes sense.

C

Okay, thank you here are some comments or some questions. One comment very interesting comment. Thank you and another question. I'm curious about how the secrets uh encrypted in a memory of the app app used, needs to use the library or you are using some kind of site car of transparency approach.

B

Well, it's it's similar to side car. Yes, it's a csi volume, basically, okay, but the secrets.

C

Are not encrypted.

B

In the memory of the application, obviously application needs to use them. Secrets are encrypted all the way before they get to the memory of the application, but at the time when they are decrypted and sit in the memory of the application, the application itself is under close watch of the identity, verification mechanism.

B

So, if some unknown so file or unknown script file is trying to get to application memory that will be identified as a break-in and application will be stopped. Okay and.

A

B

We'll be stopped, basically, it's a user choice. It's not our choice. We we allow users to to stop it or to warn about it. It's it's all flexible, but kind of the most extreme scenario is the identity. Verification mechanism can stop application when you try when it identifies the potential breaking and therefore, for as long as secret is is, is open in the memory. The application memory is being verified and uh we know it's healthy.

B

C

Okay, thank you very much. Another question: does your solution work with multi-tier andrea network policy, a and b.

B

I'm not sure I'm familiar.

C

What that means? Okay, another question: I guess the identity is based on the container image signatures uh thanks. Csi volume explains that.

C

B

Identity is not necessarily based on the container. Well, a container image is part of it, but but it's not it's not really the crucial part, because you know when application goes from uh the storage, from the image of the container to the memory it gets changed and, and you cannot basically verify the same signature that we have on the file and and we have in the memory during the execution.

B

Therefore, it's a it's a different algorithm and and the identity is based on the cryptographic uh snapshot or a specific algorithm that we've designed to snapshot executable files in a way that we can verify this signature. While the file is running in the memory.

B