Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2022, 2 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Trampoline Pods: Node to Admin PrivEsc Built Into Popular K8s Plat... Yuval Avrahami & Shaul Ben Hai

Description

Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Trampoline Pods: Node to Admin PrivEsc Built Into Popular K8s Platforms - Yuval Avrahami & Shaul Ben Hai, Palo Alto Networks

Security teams work to prevent the next container escape while attackers do the opposite. Inevitably, we sometimes lose this battle, but we can still win the fight! It's all about *containing* the next container escape - making sure a rogue node cannot take over the entire cluster. K8s has done a great job at de-privileging the node agent, the Kubelet, but nodes also host other credentials - their pods' service account tokens. Following an escape, the attacker can easily harvest and abuse tokens of neighboring pods.

In this talk, Yuval and Shaul will introduce the concept of Trampoline Pods - pods so powerful that if their node goes rogue, it could launch devastating attacks against the cluster and in some cases completely take over it. Covering managed K8s services and common cluster add-ons, they'll reveal the trampoline pods installed by popular K8s platforms. They'll also demo exploits, discuss mitigations, and release rbac-police: a tool that detects trampoline pods and K8s privEscs.

A

Hello, everyone yeah, let's get started uh so keep the session on time. So my name is indian. I'm from google I'm the moderator of this session, so it's my honor to introduce uh yuval from palo alto networks. Talk about the kubernetes security about over privileged containers.

B

Thank you. Can everyone hear me in the back yeah awesome, so I'm involved today we're going to talk about the trampoline parts and previous escalation. Kubernetes, I'm pretty excited having done a live talk in a couple of years, so let's get started with me today was supposed to be, should be high. He couldn't come at the end, but he was an equal part of making this research and a presentation.

B

So a bit about the scholar myself. We are security, researchers at prismacloud in palo alto networks, so we do vulnerability, research and threat hunting in the cloud.

B

We look for security issues in the cloud ecosystem and we try to find the threat actors that are exploiting them and we're also nba fans, and we made a couple of predictions for the conference finals when we made this talk. I got three out of four right. I'm pretty happy about that and a bit about what we'll be discussing today.

B

So today we're going to discuss start off by discussing container escapes this threat that we keep hearing about and try to understand. What's the real impact? What's the real blast radius, we'll then talk about the concept that we defined as a trampoline pods and see how they allow privileged escalation in kubernetes in general, but also in the most popular kubernetes platforms out there, based on a case study that we've been conducting in the last couple of months.

B

We'll then talk about some recommendations on how you can address privilege escalation in kubernetes and we'll finish it off with the arbuck police, which is an open source tool. We're now releasing that can help. You address privileged escalation, okay, so container escapes. Obviously, containers are great for packaging and deploying software right.

B

That's why we all use them, but they're, not the strongest security boundary, mostly because of their shield kernel, and we can expect that container escapes are likely to continue to happen only in 2022 we had at least six vulnerabilities, both in the kernel and in container run times that would have allowed for container escape, but containers can also escape because of a misconfiguration right.

B

The most well known one is a privileged containers and there are threat actors in the wild that are actually trying to capitalize on those issues and escape containers to spread in the victims environment.

B

So if, if we understand that container escapes are a threat, that's exactly going to stay, it's really important to discuss the impact, and in kubernetes at least the obvious impact is a compromise. Node right. The attacker previously had access to only one pod, but now he escapes- and he has access to all of the neighboring parts on that node, so possibly more business logic, and he also has access to more compute resources right all of the cpus, the memory of the node.

B

But if we can expect our attacker to be an ambitious one, he might not be satisfied with just the note he might want to take over the entire cluster and that's the question that we're going to try to answer today. Does a single container escape allow an attacker to take over the entire cluster and become cluster admin? And that's going to be the guiding theme throughout this stock now just to clarify what we mean by admin.

B

Basically, the attacker can do every single operation in all namespaces, so complete control over the cluster and we're also going to use another term which is admin equivalent, basically, meaning that the attacker has a permission that within one or two trivial steps allows them to become cluster admin. So in this example, it's their list secrets permissions.

B

So, in order to understand, what's an attacker or a compromise, node can do we need. We need to talk about what credentials exist on a compromise node. So, first of all, we have the cubelet credentials right. The cubeletter is the node agent obviously has a set of permissions to allow it to operate his node, but thankfully kubernetes have mostly dealt with attacks that originate from the cubelet credentials, using two components.

B

They know the authorizer and the node restriction, and what those do is make sure that the cubelet can only access resources that are already existing on the node. So, for example, the pod the run on that node and it's actually a really good cube contact from a few years ago that described that effort.

B

So the bottom line is that the cubelet permissions the default permissions of the node. They wouldn't allow an attacker to become cluster admin. They are useful for some low impact attacks so like reading certain objects in the cluster or launching denial of service attack. But if we are asking about, can a compromise not become cluster admin they're, not that relevant, but they not also host a different type of credentials. It also holds the neighboring pos service accounts, token right and their permissions vary. We really don't know it. It depends on the node.

B

It depends on the pods that it runs in, but the bottom line is that for an attacker, the permissions that are interesting are actually the parts permissions, because the cubed permissions are going to be the same, static and restricted set of permissions right, but pod's permission might be, they might be not powerful at all, but also they might be very powerful. So those are really the interesting permissions for an attacker.

B

Now, today, we're going to see scenarios where pods actually have a lot of permissions where they are very powerful and we try to name that that concept and the name we gave them is a trampoline pods, basically parts that would allow an attacker to jump around the cluster reach higher privileges and basically have some fun in your cluster.

B

Now the obvious question is: okay: are those kind of pods common? Where do they come from and to answer that we need to discuss what kind of pods run on a typical average low node right. So obviously you have application pods, the the the things that you're actually running your cluster in order to host.

B

You probably also have a bunch of add-ons, so you might be running pro medius for login or istio for service mesh or opa gatekeeper for policy enforcement, and the list goes on and there also another group of pod which we named the system pod. You may also refer them as infrastructure pods, those group of pods that normally sit in cube system and are already there when you create a cluster right and they vary between different managed services.

B

Between different distributions, but common example would be a q, proxy or core dns, and if we try to understand which one of those group pods could be trampoline, pods could be powerful. We see that system and add-on pods are actually a bit of a blind spot permission wise, because we don't configure their permissions right for add-ons. We simply, we normally just install a helm chart which actually configures the add-on permissions and for system pods. You know they were there when the cluster were created. Obviously we didn't configure their permissions.

B

Another interesting things about about those two sets of paws is that they often run as demons it meaning they run on every single node in your cluster and that really matters if they're powerful, because you can imagine that if a trampoline is not deployed as a demon set, for example, as a deployment, let's say that only specific nodes in the cluster are going to be able to escalate privileges right and an attacker that escaped might very well not be on a node, the hosted trampoline, but with trampoline demon set every single node in the cluster hosts powerful credentials hosts powerful tokens right.

B

So an attacker that escapes a container is actually guaranteed to find valuable credentials on the node. So if we try to answer whether container escape actually equals cluster admin, those are the types of trampolines that we want to look into because they can ask they can provide us with definitive answers right.

B

So we kind of screamed over a part which is defining trampolines. We say the trampoline pods are basically posed with powerful permissions, but what are powerful permissions in kubernetes?

B

That's a question we tried to answer when we did this research and when we tried to answer that answer that question we saw that there is actually no public list of powerful permissions and that's quite surprising, because that's crucial in order to understand really important and to answer really important questions like is my publicly exposed, pod, powerful and can escalate privileges. Is this add-on that I'm about to install actually installs admin equivalent to risky permissions?

B

So what we tried to do our approach to tackle this was to first define interesting attack classes. The different permission can actually carry out that makes it powerful and then we actually went over all of the permissions and tried to map them into those attack classes.

B

So, let's, let's talk about the attack classes that we identified in kubernetes? That could actually be interesting.

B

The first is permissions that allow you to manipulate authentication or authorization, for example, to change your identity or your permissions, and a very obvious example would be the permission to impersonate other users. Then you have permissions that allow you to acquire service account tokens either a retrieve an existing one or issue. A new one, for example, the least secrets permissions- allow you to retrieve existing service account tokens which are saved as a secret.

B

Then you have permissions that allow you to execute code on either on on pods in the cluster or nodes in the cluster. So, for example, the permission to create pods, slash exact is actually what allows you to do cube catalyzer.

B

Then you have a an attack class that I'm I'm really excited about, which is still pause.

B

Basically, attacks is permissions that allow you to move an existing pod from one node to another, and why would you want to do it if we assume that we already compromised the node? There might be interesting pods that we want to bring to our node either because they host interesting business logic or in our case, because they host powerful permissions. They have a powerful service account. So if we bring them over to our node, we can then exploit their service account.

B

Finally, an attack class that we're not going to get into too much is medler in the middle, also known as the men in the middle permissions that allow you to intercept traffic and the reason we're not going to get into it is because the impact, it's not a reliable attack right. You can't reliably use many in the middle in kubernetes to escalate privileges you might, but we are looking for reliable attacks.

B

Now we looked at the permissions in kubernetes and we try to classify them based on those attack classes. We're also going to release a report alongside this presentation which details for each permissions, how it enables the attack, but we don't really have time to go over each one of them.

B

It's important to know that these likes likely aren't all of the powerful permissions right, but we think it's a good start so back to a question of what makes a trampoline trampoline pods are posts that have permissions to either manipulate authorization or authentication acquire service account tokens execute code on pods or nodes, or still pause, because those permissions get you a real shot at becoming cluster admin.

B

So, let's do a quick recap, because we went over a couple of subjects, so we started off and said that container escapes are likely going to continue to happen and the main the main thing that dictates their impact is whether a powerful part, a trampoline exists on the node and we defined what a trampoline is.

B

We also discussed how trampoline demon said: install powerful pods into every single node in the cluster. So if you want to answer whether container escape actually equals cluster admin, the question we are looking for is: are trampoline demon sets installed, who installs them and how common are they? And that's really the question that we try to answer during this research? We look at the most popular kubernetes platforms and trying to find trumple and demonstrate and understand their impact on the platform.

B

So we focused on mostly on an infrastructure platform, so manage kubernetes services and distributions like eks, gke, aks and openshift, and we also look at container network interfaces like calico, celio mantra and withnet, and the idea behind it is that infrastructure components are more likely to deploy demon sets and when we looked at those platforms and searched for trump and demon sets, and we found that most of them actually installed them.

B

62 62 and a half to be exact in stone, powerful demon sets by default and in this table you can actually see for each platform whether it installed powerful demon sets, which are those powerful demon sets and what were their powerful permissions again. We there is a report that, with more details, we are not going to get into each platform now so, based on those trampoline demon sets based on their permissions.

B

We try to evaluate whether container escape actually equals cluster admin in those platforms and in half the platform based on the trampoline demon sets it did in another 25 of platforms. There were some prerequisites and in another 25 it didn't now. This is a breakdown of whether container escape actually equals cluster admin. In each one of those uh platforms, you can see that we detailed the attack based of the attack classes that are actually part of that of getting the cluster admin and for platform that had really powerful trampoline demon sets.

B

The attack is pretty short, but for ones where they were not that powerful. The attack took a few steps.

B

Now, a lot of you are probably using those platforms, so I just want to say: there's no need to panic right. There is a large prerequisite here for an attacker to abuse, trouble and demonstrate they first need to take over your pod and then escape it, and there are a lot of best practices and hardenings that can deny it and a lot. A lot of those platforms that I mentioned already removed, powerful permissions from their demon sets.

B

That being said, if you run multi-tenant cluster you in a different scenario- and you really should look into that it will- you should will be a bit more alert about that.

B

Okay, so that was a lot of theory. Let's see how an attack looks like so we obviously don't have time to go over every single platform and every attack in every platform we chose cilium, mostly because it showcases a number of attack, classes and also celio maintainers, did a great job of releasing fixes and back sporting them.

B

So what's the scenario with celium psyllium installs, two interesting components: one is the psyllium demon set a trampoline.

B

His permissions are to delete pods and to update the status of nodes, and those two actually allow you to still pause and we'll see how in a minute, then we have the psyllium operator deployment, which can actually lead secrets and by that acquire service, account tokens.

B

Now in this attack, we are starting from like how we started from the rest of the of this talk. We compromise the node right and we want to become cluster admin. Obviously we chose the weakest node, so the node node hosting the cilium operator and our approach to do that would be to first use the cilium demonstra permissions to take over the cilium operator and then use his permissions to get cluster admin.

B

So I'll just take a sip of photo before we start that.

B

Okay, I'm ready so the first step in the attack. It will be to make other nodes unscheduleable, and we do that by overwriting the port capacity in the status to zero.

B

This we do that using the update, node status permission. The second step in the attack would be to actually delete the psyllium operator. Now, when that happens, kubernetes will try to reschedule it and because all of the nodes are unscheduleable, it has to land on our node. So we successfully stolen the serium operator pod.

B

Now, the next step in the attack would be to use his easily secret permissions to actually retrieve a service account token for a built-in powerful service account that service account. The service account that we chose is the cluster all aggregation, controller or crack for short, because he can actually manipulate permission by modifying cluster roles.

B

The first step of the attack would actually to use that crack token to modify our own permissions and simply grant ourselves the entire permissions in the cluster.

B

So again, the steps are first to steal. The psyllium operator use his permission to acquire a powerful token and then use that powerful token that admin equivalent token to get our to get all of the permissions in the cluster. Now we are going to see a demo.

B

I know those were only three steps, but when you translate them to cube cattle commands, it's a lot. So it's going to be quite quick, um but if you don't, if you can follow every command, that's okay! We're going to have a like a walkthrough afterwards as well.

B

So, let's start we are in a cluster that installed celium right and the first thing we do is we emulate a container escape.

B

What I'm doing now is I'm installing a script that can actually find service account token in the file system and then configure cube cartel to use it to use the token so just to make it a bit easier and we are going to use the script to get the psyllium demons and token.

B

Now we can see that it's the cilium demon set, because when we try to do a forbidden forbidden operation, we can see that we are identified as the psyllium demon set.

B

Let's see our target, we want to steal the celium operator and we can see that is hosted on another node in the cluster. It's not our node, so the first step is to try to steal it.

B

How we're doing that we are going to change the pot capacity of the other nodes in the cluster to zero. So we are now defining a bash function that actually uses cube cattle proxy to modify the status of a node using a json patch, and you can see that what we do the operation is to replace the poll capacity and the new value would be zero.

B

Almost there got it and now we're going to use that function to set the port capacity of the two other nodes in the cluster to zero, and we do it in a loop because kubernetes actually corrects the value.

B

Now. The two other nodes in the cluster are unscheduleable, so we can actually delete the cilium operator and if it all goes well, it should be recreated on our node and we can see that it does. The node name is highlighted in red and you can see that it's a different pod name from the one that we deleted.

B

The next step in the attack would be to use his the psyllium operator permissions to get cracks token right. So we configure ourselves the q, we configure cube cattle to use, psyllium operators permissions, and we can see that we can actually now get three secrets in the cluster. So we are targeting the service account token secret of the cluster aggregation controller, and here I'm making a typo. So that doesn't work, but now it should- and we got the token and we're going to configure a cube catal to use it.

B

So now that we have that token, we can actually modify cluster all crustables in the cluster.

B

We are not yet a cluster admin, as you can now see, but we are now going to actually change our permissions, so we are now using cracks token to modify our permissions by modifying the cluster wall that is binded um to the crack service account.

B

So, as you can see, this is the cluster wall of the crack service account. It can now escalate cluster roles, but we're going to change it a bit we're going to make it full cluster admin.

B

Awesome and now, when we check the permission of crack, we can see that we can actually do every single operation in the cluster in all namespaces. So we basically achieved our goal from a single compromise node to become cluster admin.

A

B

So what attack classes did we just see in the demo? We started off by stealing a pod right still in the cellium operator pod. We then used his permissions to acquire a powerful service account token, and finally, we used that service account token to manipulate our authorization, our permissions to get class running. So this is just how the attack classes that we discussed earlier mapped to an attack.

B

Some final remarks on celium cilium actually fixed all of those issues. None of those powerful permissions remain and obviously other platforms had similar attacks. We just needed to demo something like we just needed to choose one to demo: the demo targeted the cilium cli installation, which was the default installation method when we looked at it, uh but selium is actually a special case, but there is a two popular installation method, also via helm and via helping. The permissions are slightly lower, so the impact is lower. We don't have.

B

I don't have time to like get into that, but if you want, if you use psyllium with helm and want to understand, you can see our report.

B

So, let's talk about what platforms did when we disclose those trumpet demons to them. We disclosed our findings. Every every single trampoline demonstrated we found between december 21 to february 22., and it was really a great disclosure experience. All around all of the platforms were really cooperative and understood the issue and wanted to resolve it.

B

Some approaches that platforms took to fix this issue. I think it's quite interesting. The first was simply to strip excessive or other needed permissions or to just scope down certain permissions.

B

Another approach that we saw is to move functionalities from demon, sets that run on every single node in the cluster, to deployments that only run on a few or to the control plane in the case of managed services and finally, a couple of platform actually released admission policies, for example, similar to opa gatekeeper, for example, that actually prevent misuse of those problematic demon sets. So they scope down the operation that the demonstration can actually do now.

B

You can see that there was a really good trend in just a few months, so I think it really speaks well to the commitment of the platforms that we mentioned here to resolve the issue from 62 and a half percent. Now only 25 run trampoline demon sets and a really similar thing happened uh with the impact of container escapes.

B

Now it's worth mentioning that this talks about the impact of container escapes due to due to kubernetes native attacks. If any platforms has some platform specific attacks, we obviously didn't look into that.

B

This is a breakdown of the fixes in each platforms, some things to mention are probably openshift, as it turns out just by random. They were the last platform that we disclosed to and they really had a lot of things to fix and they really did a great job with that and it's fixed are going to get released in the next version, and google also gave us a bounty for this findings, which was quite nice of them.

B

So, let's talk about what you can do to actually solve this kind of privilege, escalations, whether you are a kubernetes user, your own clusters or maybe you're a maintainer of a kubernetes project, because obviously we didn't cover so many other projects that people also in commonly installed into their clusters.

B

So, first of all, obviously, if you we need to follow the principle of least privileges, so when you can try to score permissions to specific namespaces or to specific resource names, and it's really good to take a look at your kubernetes manifest and your helm charge to see what kind of permissions are you asking for at the moment a lot of time when we are just starting a project or starting a deployment, we often give broad permissions just to make sure that everything works and those stairs legacy, even though that are not needed.

B

It's really important to understand your arbuck poster. If you want kubernetes like you should be able to say those are the powerful pods in my cluster, those are the ones that can actually escalate privileges.

B

If you are maintaining a kubernetes project, it would be great if you can actually document the powerful permissions that you are installing into a cluster.

B

Now, once you have identified the powerful permissions in your cluster and if they don't run as demon sets, it's best practice to isolate them from publicly exposed or untrusted pods in your cluster. You know there are a couple of scheduling mechanisms that you can actually use to do that.

B

And now to discuss, trampling demon sets. Obviously we saw how they degrade the security of the cluster. So when you can try to remove them, you can move privileged functionality from demon sets to non-demand set components of your platform or your cluster, although I actually you can move them to the control plane if you have control over the control plane now you can also minimize write permissions over core objects like pods and nodes by uh by storing state in a config maps or in a crds.

B

And finally, it's not really a question of drop everything or drop. Nothing right drop the permissions that you can it's still much better if a demon said that they could previously acquire tokens, can now only launch men in the middle attacks right. So it's a it's. It's a step-by-step progress.

B

Finally, you can also use admission policies when some permissions are hard to remove to actually scope down what a certain demon set can do, and we have some more data on that and examples for that. In our report,.

B

Okay, so we discussed about what to do when you want to address powerful permissions. But when we looked at this issue, we found that it's quite hard to identify powerful permission in the cluster. We don't have a lot of automated tool, so we wrote one and we named it our back police, what our book police does it retrieves the permissions of pods service accounts and nodes in your cluster and then evaluates them based on policies written in rigo.

B

So out of the box, we have 20 policies for each of those powerful permissions uh that we mentioned, so you can simply run albert police and see which are the powerful pods in your cluster. But it's also customizable, like you, can search for every pattern that you'd like to in kubernetes are back and here's an example of how the output looks. uh You can see that this shows celium, so the cluster that we just saw and it shows that celium can actually modify pods.

B

So it alerts on the specific surface accounts and specific poles in the cluster that are actually powerful. I really recommend to try it. It takes like a couple of seconds, and it gives you a lot of insight in you into your outback posture, some final thoughts, so the bright side is that issues are getting subtler and mildly right. A few years ago, issues were not complex to exploit and had a lot of impact, and you can see that here they are actually a big prerequisite of compromising a node.

B

The one downside, though, is that we can have some false confidence because of that, like you might have a cluster that passes all of the sys benchmarks and all of the best practice benchmarks, but you might not be aware that you're, a single container escape away from your whole cluster being compromised and one way to address this. Those kind of issues is to tackle vague areas in a kubernetes security.

B

We try to do that in this talk for two main questions that we felt like didn't have good answer to, like which permissions are actually powerful and what's the real impact, if container escapes the main. The main point is that kubernetes is complex enough and when we can, we should try to research. Those type of issues and try to really document and make their impact public.

B

So, with that here's a link to our report, here's the link to albert police and I'll be happy to take any questions.

A

Thank you, uh yeah. Thank you for your discovery. I think our team was busy last couple months to fix all the issues. So here are a couple questions from q a online first one is: uh why does multi-tenant scenario increase the chance of escape equals to admin.

B

um They don't that's a good question: they don't really increase the chances of container escape equaling cluster admin, but they do increase the chance of container escapes because there is more chance that you have a malicious tenant, for example. So that's what I meant by that.

A

And the other question uh yeah the other question I can answer the report. The report link is on the screen right now, so you can scan it. So another question is uh so the least privileged paradigm is still need more attention so to raise the bar a little bit. Do you think a zero percentage? Implementation is feasible for kubernetes.

B

That's a really good question.

B

I don't think we can come to a situation where every single node in the cluster, for example, doesn't host powerful credentials, but we can definitely arrive at the point where most nodes in the cluster don't host powerful privileges and that's really um what we're driving here. I think the opposite of that is the current situations where, in a lot of clusters, every node in the cluster has powerful credentials on it, and that's really not good for your security.

A

Yeah, so thank you you all. uh I think we can have some questions. I mean here.

C

Thank you uh thanks, uh say: roman prashanka. Here uh I have a question about this arabic police. uh It as you showed, as we showed it, shows some dangerous permissions, some bad stuff that could happen to the cluster, but it's already in the cluster right. uh We have.

D

Been discussing.

C

It here, as the colleagues it was a colleague if it is possible to integrate with some sort of pipeline to find out if this permissions would be appearing into the cluster. After some of the changes, for instance, with lots of pipelines for different home charts, it would be nice to know that some sort of helm apply, would sort of help. Install home upgrade would cause the bat that that pods would cause the bad permissions to appear in the chat without actually having them.

B

That's an awesome question. We actually discussed this in. We had this in the presentation earlier, but we didn't really have a time to to get to that and we have chekhov, which is open source, ifc um scanner which can actually scan from these configurations, and we just contribute with a couple of our back policies um and we expect to contribute more in the future. So we are. We are aiming for using this tool to tackle that the issue that you presented of finding powerful issues powerful permissions before they are deployed to the cluster.

E

Hey, oh hi, I'm anuja from extension, devops um in the uk just got a question. It might be a bit simple on how effective it would be to just completely lock down your network like your networking within the cluster and only enable pod to pod communication through network policies.

B

So you mean that lock down the net, the communication between nodes is that.

E

um Oh, I just meant between oh so this was. We were talking about the between nodes networking. I was talking about just between pods. So if you completely lock down your pod right and someone uses it as a trampoline pod and it can't technically network out, but then yeah maybe you're talking about you, then access access, node, networking and I missed that.

B

Thanks, I'm not sure I heard everything, but, if understood correctly, locking down networking specifically between pods is that so because of most of the attackers are actually carried out from the compromise node to the api server, and that line of communication is actually essential. There isn't much you can do about that, but obviously locking down networking like external networking and locking down pod to pod communication when it's not needed that can help you from preventing the initial compromise right.

F

Hi, hello, uh I'm working on adding username spaces support to the cubelet, and I was wondering if most parts at least the compromise part runs in a username space and and that username space is on every part in the host run as a different uid in the yeah in the host name. Namespace like uh would it be possible to compromise the service accounts, as you cannot read them, because your different uids would that help? In this case.

B

Obviously, usernames, that's a really good question. Obviously, usernamespace help a lot with containers, isolation, so their job would be to prevent the container escapes and then again, usernamespaces alone. I wouldn't like rely only on that, but if you have a more powerful sandboxing solution like a let's say, cutter containers or g visor and there there is actually that actually does sandboxing to a higher degree and then it's it's less um problematic to have a powerful pods next to let's say publicly exposed one, it's still not perfect, but to a question.

B

Yes, usernamespaces do help, obviously, with every container isolation.

D

uh Hi, um I I was wondering about two potential: well one mitigation and one possible design, um whether something like tell us like a very minimal node with no shell. How much would that kind of help against this attack and then also in kubernetes, if service accounts were a separate resource to secrets?

D

Can you see that offering any benefit to these types of attacks as well.

B

So I think there were two questions. One was related to removing a binaries from the node, removing the shell right and the second was about service accounts. Not being secrets is that there, so I I'll actually start with the second question. So there's actually now a a kubernetes enhancement proposal.

B

That's just landed in 124, where service account tokens are not automatically created as a secrets for a new service accounts, so that obviously reduces the impact of one powerful permission, the least secret permission, and but you should note that I don't think that in 20126 um existing service account tokens would be removed from secrets for your question about the removing binaries from nodes. Obviously, like it's a good hardening, I don't think it's like something that can stop this completely and I and I think it's also a bit how to implement that. But yeah.

B

I think, for the future. A lockdown node is definitely interesting to look into, and I know aws tries to do something like that with a bottle rocket. For example,.

A

Yeah, thank you. uh I think we are right out of time. uh If you have more questions, feel free to email, eval and you can connect connect with him through the cobra kong platform. Thank you. Everyone give him another.

F