 Hello everyone and thank you for joining me for today's webinar and thank you CNCF for hosting it. My name is Travis Rogers. I'm a developer relations engineer over at Teleport where we provide identity native infrastructure access for engineers and machines. Now we're going to see a demo of how Teleport works with Kubernetes later, but that's not the main reason we're here today. The main reason we're here today is to discuss Kubernetes clusters and how to secure them. Now, if at any point during the presentation you have questions or at any point afterwards, my email is right here on the slide at travis.rogers at goteleport.com. I'd love to hear from you. Feel free to email me. But if you want to access the broader Teleport community, then check out our community Slack. You can get to that at goteleport.com slash Slack. We are an open source project, so the link to our GitHub is right here as well. And if you want to try it out, we have a labs page where we actually spin up the servers and teach you how to use it. That's at goteleport.com slash labs. And finally, you can find us on YouTube where we do tutorials, webinars, videos like this. So with all of that out of the way, let's get started with the webinar. Okay, so here's a diagram of how I think people learn Kubernetes. So they're at this starting point. Maybe their job is asking them to learn these skills, to manage their clusters for them. Maybe they're learning it on the side. It's like a hobby or an interest. But usually you start out here and you think, hey, I got this checklist, I got to check off to learn Kubernetes. But what really happens is you get pushed into this scribble fast. There's just so many things to learn with Kubernetes, so many moving parts. It's a pretty complex machine. So you get in there and you realize, hey, wait, I need to, I don't even know containerization, I got to learn that first. And then you get in there and there's so many little parts to it. It's just pretty complicated to learn Kubernetes exhaustively. So normally you get in here, you scribble around a little bit, you come out and you understand Kubernetes. Great. At that point, you're able to get your cluster up and running. You're able to deploy a cluster. You're able to deploy an application without errors, because we all know the first time we try to do that, we get lots of errors, crash loop backoffs, things like that. So you can get the cluster up and running, you can deploy your application without errors. It's running out there in Kubernetes. And you can navigate the cluster. You can use kube-cuddle. You know about services and stateful sets and pods and all of that good stuff. But there's one main key that's left out here. And that is the fact that Kubernetes isn't safe by default. You've deployed your cluster, you have applications running in it, you can manage the cluster, but you didn't do anything to the cluster's configuration. And that configuration that was deployed untouched isn't safe by default. It has to be configured to better increase its security posture to make your cluster more secure. Now, let me show you something that reinforces that. So this is the 2022 state of Kubernetes security report by Red Hat. So Red Hat polled 300 DevOps engineers and security experts. And here was the result basically. Respondents worry the most about exposures due to misconfigurations in their container in Kubernetes environments. So almost half of all of these people polled worried about exposures due to misconfigurations in their container in Kubernetes environments. This was nearly three times the level of concern over attacks, which was 16%, and with vulnerabilities as the second leading cause of worry at 28%. And so in this video, I decided I would try to give you some tips on tightening up the security posture of your Kubernetes cluster, your default Kubernetes cluster. Now, if you're using managed Kubernetes like AKS or EKS, you get a lot of these security benefits. But if not, you just deploy your cluster, you're going to have to do things to make it more secure. And that's what this video is about. So we're going to look at five ways that you can secure your cluster. So let's secure Kubernetes. Okay, so the first security measure we're going to talk about in regards to your Kubernetes cluster is at CD security and secret management. So you probably already know, at CD is a highly available key value store for cluster data, including your secrets. So securing at CD is critical to a cluster security. If someone obtains read or write access to at CD, it's basically giving them root access to the cluster. So you're going to have to do your due diligence to secure this vital piece. Now, how do you do that? Well, we're going to give three ways today. First, you need to encrypt your at CD data at rest. Your default Kubernetes cluster does not do this. Your at CD data and your secrets are in plain text. So if an attacker were to get your at CD, they can just read your data as plain text. So the first thing you can do is encrypt that at CD data at rest. And I'm going to show you hands on how to do that today. So let's go to the Kubernetes documentation. There's a page called encrypting secret data at rest. And basically there's four steps. First, you need to create an encryption configuration object. So here's the encryption configuration object. You specify your resources. So here we have secrets and config maps. And then you specify your providers or your encryption type. So today we're going to be using AES CBC as seen down here in the tutorial. So that's the first step. Create this encryption configuration object. After doing that, you need to add three things to your API server manifest file. So let's walk through this. Let's create this encryption config file first. So I'm going to take this information and copy it. Now I'm using mini cube today is my Kubernetes cluster, you can use whatever variant you want. But what we want to do is we want to SSH into mini cube. So I'm going to do mini cube SSH, because we want to take this encrypt encryption configuration object created as a file on the control plane node. So I'm going to SSH into my mini cube server. And then I'm going to CD into Etsy, Kubernetes. And I'm just going to create a folder. So pseudo mcder. I'm going to create a folder called ENC. This is going to be my encryption folder. And I'm going to CD into that. Now I'm going to do a pseudo vim. And I'm going to create a new file called encryption configuration dot YAML. And inside of that file, I'm going to paste the contents we just copied from the Kubernetes documentation. So I'm going to go up here first, I'm going to erase this other resource. And I'm actually going to erase config maps too, because that's not really pertinent to what we're doing today. So we have resources secrets, and we have this provider a ESCBC, we have a key named key one, and a secret, we don't have a secret yet, we need to generate a secret. So to do that on the documentation, there's actually a command we can run. So let's go back there, run this command, this will generate us just a random string of numbers and letters. So I'm going to open a new window, and just paste that in, and copy this string of characters. And that's going to be my key. This key is what's going to encrypt my secrets. Come here and just paste that. And I'm going to save it in that location. So right here in this ENC folder, I have an encryption configuration file that much is done. So the next step is you want to add this encryption provider config flag on your cube API server manifest file. So you want to add this as a flag, and have it point to that encryption configuration object you just created. And then we need to add that folder is a volume and then mount it. So let's do that. So I'm going to go back a folder, go to manifests. And within that there is a manifest file called cube API server. So let's do pseudo vm cube API server open that up. So the first thing we want to do is we want to add that encryption provider config flag. So let's do this in alphabetical order. Just going to put it right below this encryption. And what was an encryption provider config encryption provider config. So encryption provider config equals and then the path to our file. So Etsy, Kubernetes, ENC encryption configuration dot YAML. So it points to our file. That's the first thing. Second, you want to go down and I'm going to do a page down, down to the end and add a new volume. So let's do host path and our path is going to be Etsy, Kubernetes dot ENC. That's where our encryption configuration file is is in that folder. And we'll do type directory or create. And then as far as a name, we'll just put ENC. Now we need to scroll up to the volume mounts section so we can mount this. So let's go right below this and do mount path. And it's going to be the same location Etsy, Kubernetes, ENC name is going to be ENC and read only is true. And that's it. According to the documentation, those are the three things we need to do. And so let's go ahead and save that. And when we do that, it's going to recreate that API server pod. So I think when we exit, we're not going to be able to do anything yet. Okay, get pods. Yeah, we can't do anything yet. It might take a minute to get this back up and running. But when this comes back up, any secrets that you create from this point on will be encrypted. And we'll go and check that to make sure that it's working. Let's try it again. Okay, get pods. Okay, our API servers back up and running. So what's next in the documentation? How do we verify this? So verifying that data is encrypted, we first want to create a new secret. So we're going to create a new secret. And then we're going to read that secret out of Etsy D using Etsy D cuddle and see that it's encrypted. So let's create a new secret. So I'm going to run this command. And it's going to create a secret called secret one. Secret created. And then, like I said, we're going to read that secret out of Etsy D. Now they give a command here that you're supposed to run on the Etsy D server. I'm going to add a cube exact to it so that I exact into that Etsy D server and spit out that secret. And then I'm going to do the hex dump. So it's the same as this. I'm just adding a couple commands to it. And then I'm separating the hex dump part of the command. So it's going to go like this. So I'm going to paste in this command. And it's going to spit it out as a file called secret. And then I can do a hex dump. So cat secret hex dump dash C hit return. And you'll see that we have the AES CBC encryption here. So when it says key one, it's going to be encrypted. So as long as you have the AES CBC here showing, you know that your data, your secrets, are encrypted. And this is going to encrypt all of the secrets going forward from this point. Now, if you want to go back and encrypt all the previous secrets that you had before this, just follow the documentation down where it says decrypting all data, you're going to move this identity value, and you're going to run this command and that encrypts all of your old secrets. So that's encrypting your Etsy D data at rest. That's the first thing you can do. But there are a couple of problems with this, the way we did it. So the first problem is going to be that the encryption key on the server is in plain text. So if somebody gets on your control plane node, they can just check out that encryption configuration file and there's the key and that key unlocks everything. It's in plain text. The second problem is that you face manual key rotation, which can be pretty cumbersome. And third, this encryption type is actually not recommended. The one that they show on their website, the one that we just followed. So if you go here and go back up to this provider chart, you'll see that there's a number of providers. So we use this AES CBC provider. The strength for that is weak. It's not recommended due to CBC's vulnerability to padding oracle attacks. So what else do we use? Well, we could use secret box, which is strong, but it's a newer standard and may not be considered acceptable in environments that require high levels of review. There's an AES GCM that is not recommended for use, except when an automated key rotation scheme is implemented. And then there's identity, which is no encryption. So what do they recommend? They recommend the KMS provider here, the recommended choice for using a third party tool for key management. And the key to this KMS provider or key management service is that you can manage your encryption key outside of your cluster. So think AWS KMS, Google Cloud KMS, or HashiCorp Vault. There's some great documentation for these providers out there, and that is the recommended way to go. That is the strongest and has the most benefits. Now let's move on to number two. So the number two way of securing your etcd or secrets is to restrict access to your etcd. And that involves isolating your etcd server. So the only thing that should talk to etcd is the API server. What you can do is stick a firewall between the two just to ensure that only API server traffic can get to etcd and nothing else. And then finally, the third step is to ensure that the API server is using TLS. All right, so the second way you can better secure a default Kubernetes cluster is by using network policies. By default, Kubernetes allows all pod to pod traffic inbound and outbound. So see here in this diagram, we have a namespace, all pods can talk to other pods freely. But if an attacker were to gain access to one of those pods, they would be able to freely move to other pods. So this is a problem. We don't want this traffic to be wide open, and it is by default in Kubernetes. So what's the solution to this? Well, the solution is network policies. Network policies restrict unnecessary namespace to pod to pod access on the network or transport OSI layers. So a better way to handle this with network policies is to first set an all out deny policy. So instead of allowing all pod to pod traffic, allow no pod to pod traffic in a namespace. And what's neat about network policies is they are additive. So once you deny all this traffic, you can then add on traffic rules as needed. So set an all out deny policy, and then add allows as needed. Here's an example. Let's say you have a front end application in react. You have a back end application or pod in dot net, and you have a database, a MySQL database in another pod. By default, these three pods can all talk to each other in a namespace. And we're assuming here that they're all in the same namespace. But ideally, the front end shouldn't be able to talk to the database and the database shouldn't be able to talk to the front end. But the front end should only be able to talk to the back end and then the back end to only talk to the database. So how would you apply network policies in this scenario? Well, first we would set again this all out deny policy. So set this network policy to this namespace and none of these pods can talk to each other. And from there, we can add allows as needed. So if we add another network policy to allow traffic from the back end to the database, we get this. So this network policy is applied to pods with this label. It's ingress, and it matches the labels with back end at port 3306. So this network policy allows our back end to talk to the database. It allows ingress into the database. We would also want to create one from the front end to the back end. And by doing so, we restrict this wide open access between pods to allow only the access that's needed. So this is network policies. And if you need this kind of protection, not at the network or transport layers, but at the application layer, then you can look into a service mesh solution like Istio, which allows networking policies at the application layer. All right, number three on our list and similar to the previous is pod to pod communication. By default, Kubernetes allows pod to pod traffic unencrypted. So previously, we saw that Kubernetes allows free flowing networking. Well, here we see that that traffic is unencrypted by default. And we definitely want to encrypt our data. So right here in the diagram without TLS, we go pod to pod in plain text for any attacker to pick up with TLS, we go pod to pod with encrypted traffic. So what's the solution to this? Well, the easiest solution is to introduce either Istio or linker D to your cluster, because both enforce mutual TLS between meshed pods. And that's enabled on both by default. So by introducing either one of these solutions, you get mutual TLS within meshed pods. In the case of Istio, Istio deploys an envoy proxy to each application container that will enforce TLS encryption within the service mesh. So here's the Istio mesh within that within each application container. There's an envoy proxy that enforces TLS encryption. And if you go with Istio, make sure you set the M TLS mode to strict and not permissive strict enforces TLS only permissive allows TLS and plain text. Number four, let's look at secure access. So any user that presents a valid certificate is considered authenticated. With that in mind, we want to disable anonymous auth, and we do that in the cube API server manifest like the one we visited earlier, we do that by adding this anonymous auth equals false flag that will disable anonymous auth. Now if anonymous auth must be used, like in your circumstances or with your company, you need anonymous auth for some reason, our back should greatly limit what these users can do. So use our back to greatly limit anonymous users as a whole. Number two, you want to disable the insecure port. So the API server actually has a secure and an insecure port, you want to go in and disable that insecure port. Why? Because this insecure port bypasses authorization and authentication checks. And to do that, again, you go to the cube API server manifest and you set a flag of insecure port equals zero. Number three, you want a well maintained RBAC. This is not something you set and forget. This is something that is well defined and well maintained regularly. So that's a well maintained RBAC. And then finally, you want to introduce some kind of corporate solution management. So admin should consider managing normal user accounts with corporate solutions like Active Directory, Okta, et cetera, via OIDC. Now an open source application like teleport provides secure access to Kubernetes clusters by way of short lived cube config files and certificates via single sign on. And I want to demo that for you today. I want to show you how secure and easy it is to access all of your Kubernetes clusters via teleport, the open source version of teleport. So I'm going to open up my teleport cluster UI. And I'm actually going to log in passwordless. So I can choose passwordless. And then I'm going to use a passkey that's stored on my phone. If you're not familiar with past keys, they're a new and secure replacement for passwords. Teleport supports it. And I think more and more applications will as the year goes on. So I'm going to scan this with my phone and sign in with my passkey. Okay, so this is the UI of my teleport cluster. I'm signed in as teleport admin. That's a user. If I go to Kubernetes, I see that I have no Kubernetes clusters to access via teleport. So we need to add one. What's neat about this is that if you go to team, you can create users and you can assign them roles here in teleport. So you can enroll all of your Kubernetes clusters here that you can access. And you can use our back to control who has access to what. And we'll see that in just a minute. So to add a Kubernetes cluster, just go to Kubernetes, add Kubernetes next. And there's this wizard that walks you through it. So I'm going to copy this. This will add the teleport agent chart to your charts repository. Let me go to my terminal and put this in. Again, I'm running a mini cube cluster. All right. So my helm repo is added. And step two, generate a command to automatically configure and install the teleport agent namespace. So teleport service namespace, I'm just going to put teleport is going to be on my namespace. The name of my cluster is going to be a mini cube cluster. And click on generate command. What this does is it generates a command for you to enroll your Kubernetes cluster with teleport. So the first thing it does, it creates this prod cluster values file with some information. And then there's a helm install based on the information of that file. So let's do this separately. Let's capture this first part and create that. All right. So we have now have the prod cluster values file. And then we do this helm install. Now I'm going to add a label to my cluster. So I'm going to open up VS code, go to new file, text files find, paste this in. And then I just want to add to this command a set labels ENV equals dev. So I want this cluster to have a label with ENV equals dev. It is an environment dev cluster, not a prod cluster. That's all I'm doing here. So copy this command, go to my terminal and paste that in hit return. And our teleport agent has been deployed. Let me clear the terminal here. And while the container spinning up, this wizard takes you through another couple of steps of setting up access and testing the connection. I'm not going to do this because I don't have any roles configured yet. So I'm just going to exit out of this once this is done. So I'm not really concerned about this timer that detects the teleport service. All right, if I check my pods now K get pods. You'll see that my teleport agent is running. So if I go back out to teleport and click on Kubernetes, I should have my cluster listed. That's how you enroll a Kubernetes cluster to teleport. So from here, I can connect to the cluster. And you do so by clicking connect and following these instructions. So number one, log into teleport. So teleport comes with a couple of CLIs. There's the TCTL CLI, T cuddle, which is the administrative CLI. And then there's this TSH CLI, which we can use to log in and log out and things like that. So the first thing we need to do is log into teleport via the command line, because that's where we're going to be using cube cuddle. So I'm going to paste that command in here. I'm actually going to erase this last part. And here I have the proxy flag for my proxy, which is teleport tr dot asteroid dot earth. I have my off and my user of teleport dash admin. So this will log me in. Enter my password, my password and then tap any security key. I'm using my Yubi key. So tap that for second factor. And there we go. I'm now logged in to teleport via my teleport user, teleport admin for 12 hours. And this is configurable, but valid for 12 hours. I have a 12 hour certificate. So I've logged in. What do I do next? Well, next is an optional command you can run to set a different cube cuddle configuration. We're going to use the global. So we're going to skip to step two, which is select the Kubernetes cluster. Now let me show you this. If I do a cube cuddle config view, you'll see that my current context is mini cube. We don't want that. We don't want to access mini cube directly because, you know, that's on my local computer. We want to access this Kubernetes cluster through the secure functionality of teleport. So that's what this command is going to do. This is going to issue us a short lived certificate. So TSH cube login, mini cube cluster. So let's run this command. Let me clear this run this command logged into Kubernetes cluster, mini cube cluster, try cube cuddle version to test the connection. Let's try that out. Cube cuddle version. All right, everything's working. Now if we do cube cuddle config view, you'll see that my current context is now teleport tr dot asteroid dot earth slash mini cube slash cluster. So it looks like we're using teleport. And the last command is to connect to the Kubernetes cluster. So we just need to run cube cuddle get pods. So clear this again, cube cuddle get pods. What do you think is going to happen? Well, this user cannot access Kubernetes unable to list resource pods. This user cannot request Kubernetes access has no assigned groups or users. Why is that? Because our teleport admin doesn't have any roles. It has no privileges to access this Kubernetes cluster. Even though this Kubernetes cluster is enrolled with teleport, we still have RBAC in place to control who has access to what. So let's do this. Let's go back to team and roles. Let's create a role for Kubernetes admins. So create a new role. I'm going to call it here Kubernetes admins. And this is a default template. So I can erase everything below this, because I don't want any other privileges with this role. And I'm actually going to erase this Kubernetes users because I don't need that at the moment. And under Kubernetes groups, I'm going to put system masters. And this is never recommended. This gives you admin access to the cluster based on a system master's default role that Kubernetes has. But just for demonstration and this Kubernetes admins group, let's do that. Click save changes. And then let's go to users and my teleport admin user, let's edit and add that role to that user. So Kubernetes admins and save. Now our teleport admin user has a role for Kubernetes admin access. So let's go back to our terminal. Let's do TSH logout because we need to get a new certificate that role is in the certificate. Let's do TSH login again for teleport admin and login. All right, great. And you'll see now that a Kubernetes cluster says mini cube cluster in our Kubernetes groups for this user is system masters. So at any point you can do TSH status to see your status. And now that we have that system masters group, we should be able to do K get pods. And it do it successfully because we now have the privileges to do so. There we go. We can do K get services and whatever else. So that is the role we're going to give to teleport admin. But what if we have other users come on the scene? Like let's imagine that we have this role, we have these users come in that you just want to give them read access. They should only be able to read the pods of a Kubernetes cluster. So let's create a new role. Let's call it developer read. And again, let's erase all this stuff. We don't need it. And for Kubernetes groups, I'm going to erase the users also for Kubernetes groups. Let's imagine there's a group called developer read. This is a developer read only group. So let's save this. And what we're going to do is we're going to create some roles in Kubernetes. So this is not teleport. This is Kubernetes related. And I have some examples that we're going to use. So we're going to create a role in Kubernetes called dev read. Resources will be pods and pods slash log. And the verbs will be get list watch. So a read only role. Then we're going to create a role binding called dev read binding that binds this role, this dev read role to a group called developer read. So let's go ahead and do that. And actually, I have both of these roles already on my system. So let me just apply that. So cube cuddle create dash f dev read role. I think it's called dev read role. Let's create that role. All right. And then we create the role binding. And again, this is not teleport. This is just Kubernetes. This is creating a group in Kubernetes called dev read that only has read access to pods. So now in teleport, this role that we created edit gives access to a Kubernetes group called developer read, which is the the group that we just created in Kubernetes. So what I can do now is I can create a new user. Let's go to users create new user. Let's call him Bob. And let's select a role. Let's select the developer read role. So Bob is a new developer on our team. And all he needs in Kubernetes is to read pod information. So let's save that. And here's a link and an invite link that I would send to Bob. So I'm going to send this link to Bob. He's going to click on it and set himself up. So get started, Bob, let's create a password for Bob and click next. And we're going to use a hardware key. Try another way in a USB security key, which is my UB key and registration successful. Great. So here's Bob. Bob has no access to servers applications. He does have access to this mini cube cluster because we gave him access. So let's go and log in as Bob. Let's do a TSH log out and do a TSH login as not to teleport admin, but as Bob. And let's see what Bob can do. So Bob's logging in. Bob should only be able to read from Kubernetes. So K get pods. Let's see how it goes. No resources found in default namespace. Great. What about K get services? Bob can't do that because he is in the read only group. Forbidden, user Bob cannot list resource services in the namespace default. So this goes to show you that you can have lots of developers and whoever's on your team. And you can give them different access to this Kubernetes cluster securely through short lived cube config files. So teleport admin has admin access to the cluster. Bob only has access to that developer read group. Now one more thing I want to show you, let me log out as Bob and log back in as teleport admin. Other sign in options, password list. So try another way. Again, I'm going to do my pass key. And now if we go back to team and roles, if you look at this role developer read and go to edit, there's a section called Kubernetes labels that has these two stars. This means that basically you can access any cluster given that you have the right group or the right other access. But this labels gives you access to clusters with any label. Well, remember we added here this ENV, if we go back to Kubernetes, we added this ENV DEV label. So let's say that this developer read, we only wanted them to access prod clusters. We could come in here and do ENV prod. And then I can maybe change the name to developer read prod. But what this is going to do is this is going to take Bob and not allow him access to that cluster because that's a dev cluster. He only now has access to prod clusters. So there's a lot of ways you can limit access for your users. Now the final thing I want to look at in this demo is audit logs. So if you go to activity and go to audit log, we can see everything that everybody did. And more importantly, all the kubectl commands ran. Now remember, Bob has access to the developer read group. So everybody using that developer read group, the logs are not really going to help us a lot. We're going to see that somebody use developer read developer read different people. Well, this audit log is going to show us which user did what with lots of info. So right here at Kubernetes request, user Bob received a 200 from get pods. So this tells us that Bob ran the kubectl get pods command to this Kubernetes cluster, mini cube cluster. Imagine if you had 15 clusters in 50 users, you would be able to see the audit logs for every individual person here. If you need details on it, there it is more information here in the details button. We see here that Bob got a 403 when he tried to get services. So that audit log is very, very, very helpful for teams. So here's a diagram of what we just saw. So the users are going to do this TSH login to log into the teleport cluster. From there, from their machine, they can run kubectl get pods or whatever commands to the Kubernetes cluster. At no point do they access the cluster directly. They only talk to this teleport proxy. The Kubernetes cluster runs this teleport agent and has an encrypted tunnel back to the teleport proxy. And you can even put a firewall there for more protection. So that's the section on secure access and the demo of teleport. Let's move on to number five. Fifth and final on the list is pod security. So here's a bit of a backstory. A few years back, I got put on a team and none of us really knew a lot about Kubernetes or containerization. And we were asked to containerize a lot of apps, create helm charts for those apps and deploy them into Kubernetes. So going back to that first diagram, we started that journey of learning Kubernetes and containerization and we thought we knew a lot. So we got these applications containerized, we figured out helm charts, we created helm charts and we deployed them to Kubernetes. But we were application developers. Once that application was running, we, you know, high five, checked it off the list, we're good to go. We didn't think much about pod security because we didn't know a lot about it. But pod security is very important. If you're pulling images, docker images or helm repos from third party websites, they possibly could introduce problems like root access or some misconfigurations that weaken your cluster security. And the reason I gave that example is because there are a lot of talented application developers that containerize applications, they throw them into Kubernetes and they're good to go. They don't know a lot about maintaining Kubernetes and Kubernetes security. They're not really supposed to their application developers, but you need somebody on your team to overlook that security. So when it comes to YAML configurations that are introduced to the environment or containers that come into the environment, they need to be audited. Now you can do this manually by having someone or team do that, or you can look into vulnerability scanners as listed here. You got cube striker, cube score, cube lender, vulnerability scanners that will look for potential holes in your YAML and your containers and try to find that problem before they come into the ecosystem. You can also utilize security contexts. As you can see here, there's a security context on this pod with run as non-root as true. And what this does, if you have this setting, the cubelet will refuse to start any image that defaults to the root user. So hopefully when you containerize your application, you set a user ID and a group ID, but sometimes if you're not careful, those containers will come over with root access. And by setting this security context setting, it will refuse to start the image that defaults to the root user. That's another protection. And there are more security contexts, things you can look into. You can see it here on the API page. So again, make sure your YAML and your containers are audited when they come into the ecosystem, either manually or with vulnerability scanners, and then use tools like the security context to make sure none of your pods are running as root. And with number five being done, that leads us to our conclusion. So again, five things to check on your default cluster is number one, your etcd security or secrets management. Number two, network policies, use network policies. Number three, pod to pod communication. Make sure that's being encrypted. Number four, secure access. And number five, pod level security. And with that, thanks a lot for joining me in this webinar today. I hope you learned a lot.