 Awesome. Thanks for the intro and thanks everybody for joining me to talk about the CKS. I already see some questions in the Q&A, so I'll get to those as I go through the webinar. But yeah, as things come up, as I talk about stuff, feel free to throw questions in there. I'll answer as much as I can as I go. So again, CKS, what you need to know, can't give away too much, not going to tell you exactly what you need to know, but we're going to cover the broad range of topics. I'll give you my tips as to how I passed it, what I thought about it, and where I think it's moving forward in the future. So again, what we're going to cover, we're going to just intro CKS, what it is for people who are joining who don't have a certification. We're going to talk about the exam structure, we're going to talk about the format of the exam too, because it is a CLI and more hands-on exam, so it does kind of jar some people at first. Then we're going to go into section breakdown. So based off the exam structure, what the CNCF and Linux Foundation has told us to expect in the exam, we're going to look at that. I'm going to break down basically what my guess was going into the exam and how accurate it was, so to speak, without giving away too much. And then lastly, I'm going to talk about my general tips, and I'll sprinkle some general tips as I go as well. So, why Kubernetes certifications, right? CNCF announced it at KubeCon last year in November about the CKS, the Certified Kubernetes Security Specialist, and I think it was a long time coming. It was honestly due, it really just showed in terms of basically the education sort of 101 tracks that they pushed in KubeCon and really sort of trying to bring a broader community into Kubernetes. I think security is obviously a hot topic, and I think it was great that they brought the CKS in. It's the third certificate, so it's joined the CKA and CKAD, and it's, again, command line and hands-on focused exams, all three of them. And yeah, look forward to talking about it. The constant question I already get about these CKS is, is the CKA and CKS worth pursuing? Do you think that it actually helps you in jobs or get job offers or things of that sort? So I actually find that when I first started working with Kubernetes, I gained a little bit of hands-on experience at my job, and then studying for the CKA really actually helped me just go and learn and find out about one, all the resources and all the community tools that are out there. So it really gave me more broad view of what the ecosystem looked like, how to actually work in the Kubernetes ecosystem, and I felt that it was really worthwhile regardless of the job offer or the jobs that came along with it to actually become ingrained in that community. So moving into exam structure, if you've taken the CKA, you'll understand the CKS structure. It's the same sort of format. It's two hours long. You have to get 67% to pass. It's listed as 15 to 20 performance-based tasks, but then they kind of give it away on the next slide about how many tasks you're going to have to perform. So right now it's using 119, actually a big push. So you'll see Kubernetes updates being pushed. 119, we want to move people off of 115 into some of the newer Kubernetes versions as 115 isn't really supported by Kubernetes right now. So 120, 119 and 118, I believe are still supported. So make sure we're upgrading and making and taking advantage of those new features. It costs $300 USD if you're paying attention. Sometimes you can always get some things on sale, or I think some people have reported like honey working and getting them a little bit of money off too. So worthwhile doing that. A free retake, I actually think, I think it's great that they offer this because sometimes when you get into the test, it can be, again, like I said, a little jarring. So free retake is really useful. It's valid for two years. You have 12 months to take the exam, and you need a CKA in order to take it. I get questions as to why the CKA is required to take it. One, the CKS out of the three tests, I believe, is the hardest test to pass. I think that it's not when you're looking at security, you're not just looking at Kubernetes, right? When you take the CKA, you're looking at basically Kubernetes as an administrator. When you're getting into security, now you have to look at whole life cycles. So you have to look at node security, network security, Kubernetes, image security. As we've seen in the last month or so, supply chain securities is a big factor. So again, I really believe that the CKS, that the CKA should be a requirement before the CKS. Now, into exam format. So each task on this exam must be completed using a designated cluster configuration context. If you take in the CKA, you'll understand what this means, you know, you control use context. During the test, you'll get 16 clusters. Every single question is gonna require a new context. This is so that you don't do something to the previous environment that trips up the next environment. It's a good format. It's just sometimes can get a little bit confusing if you're flustered that, you know, you might be in a node diagnosing something and you do a use context. Oh, it doesn't work. Oh yeah, I have to exit out of the node to get to sort of the orchestrator node, so to speak. So at the start of each task, you're gonna get an info box that's gonna provide you with the cluster name and context and the master and worker node host name. This makes it so that you get SSH into nodes a lot quicker and really just make sure that you read each task thoroughly. Okay, so like I said before, you can switch the cluster configuration using a keep control config use context and the nodes making up each cluster can be reached via SSH. Now, when you get onto into the node, even if you're in that kind of that main orchestrator hub node, you have elevated privileges. So you can install and run pretty much anything you want. There's no need to assume elevated privileges. Like I said before, you must actually return to the base node. So when you get into the test, you're gonna have this base node that, you know, you can write files to save files. It's always gonna be that constant node that you get into. If you SSH into a node, just make sure that you come out. But if you're in the orchestrator node and you exit out of that, it's gonna basically refresh the environment just so you know, just be aware of where you are. Now, you can use keep control in the appropriate context to work on any cluster from the base node. But when you're in the, if you're in a specific node and like a control play node or a worker node, you'll only be able to use the keep control in that node. Now, subtle thing there is that you can actually go into a node and diagnose things in the cluster from within the node. So if you are doing something in the node and you wanna run keep control, you don't have to actually exit to run it. You can run it directly from within that node, which is really useful. So you're not wasting time going back and forth. Yeah, so further instructions for connecting to nodes are provided during the test. Just make sure you read every question thoroughly. All the information is there. It's just up to you to know what to do with it. And I slid this little caveat in there. VI and Vem are the default editor during the exam. So if you have a favorite editor, you are going to have to install it. So that means if you're on the base node and you have favorite editor, when you get in, install it and use it. Now, if you're doing keep control, edit something, VI is obviously the default editor. So you can either change that in the config file or just leave it and kind of learn to edit with VI on the fly. It's nothing crazy. So kind of skip through that, but exam sections. So six sections were outlined by the Linux Foundation, the CNCF for this test. Section one is cluster setup. So we are talking for network policies, benchmarks, Ingress objects, protecting node metadata and minimizing access to graphic user interfaces. Graphic user interfaces are really important. Just in general, protect your services, make sure that our no port services aren't open. We can set up Ingress objects correctly so that we don't have services that are connecting to the wrong Ingress. If you have multiple Ingress controllers in a namespace, for example, and benchmarks are also really important. The CIS 1.5 and 1.6 benchmarks and also some open source tools that can help us identify issues in our cluster. Section two, so cluster hardening. So we're moving into accessing Kubernetes API, role-based access control service account defaults. So maybe we have environments that have defaults set up. How do we change those defaults? How do we manipulate or edit things on the fly? And update Kubernetes frequently. That was sort of when I was following the development, I actually think this might have been slated in at the end, partially because we want the community to move off 1.1.4, 1.1.5, 1.1.6 and move into some of the newer functionalities and newer security features that come with 1.0.8, 1.1.9 and 1.2.0. And I actually think for those who aren't aware, there were three Kubernetes releases last year. There is schedule three releases this year, so the release cadence has also slowed in order to accommodate people moving forward and taking advantage of those features. So section three, minimizing host OS footprint. I thought this was really interesting, especially because you can't really control the environment. So how do you minimize the node OS footprint? Normally that would fall on more infrastructure role, but I think since security ties into everything, I think it was great that they highlighted this. Minimizing IAM roles, minimizing external access to the network and using app armor or SecOmp for kernel hardening tools as well. Just real quick, what does it mean 12 months to take it? So when you sign up for the exam, you have 12 months to take your two exam chances, so to speak. So if you sign up and you don't take it, you can't take it after 12 months. All right, can I get rid of that? So moving on to minimizing microservice vulnerabilities. We want to set up OS level security domain. So we have pod security policies, OPA, security contexts, all different aspects of enforcing appropriate security for the different containers, especially at runtime, security contexts being at a pod and deployment level and then things like pod security policies and OPA enforcing at a cluster level. Managing Kubernetes secrets, Kubernetes secrets is always gonna be a topic as to how to manage it. We do not want our secrets in our configuration, in our YAML files, right? Or in our Docker images. So just make sure that we're a way of secrets workflow, how to manage them, how to access, remove secrets and the general life cycle of secrets. Container runtime sandboxes. So this will be sort of a continuing theme moving forward, especially with Kubernetes, deprecating the Docker shim, deprecating the, what's the word for it? They're deprecating their support, sorry, for the Docker shim. So Docker said they were gonna pick that up, but now there are other runtimes. So for example, Red Hat uses podman and cryo, right, you see G visor. You know, you might have multiple runtimes running on the same node. How do you schedule that? How do you isolate the runtimes? Those are some of the questions that are going to continue moving forward. Hey, Murat. Yeah, and so I actually saw a question about this, implementing pod-to-pod encryption using MCLS. One of the questions was, are we expecting something like a service mesh? Can't give away too much. Let's say that you should understand how to implement pod-to-pod encryption using MTLS at its core functionality. Maybe it's something simple, like add a certificate to an Ingress or implement something that you have to do. But in general, just worth knowing, I'll get more into this at the end when I talk about tips and tricks. Section five, supply chain security. So again, this was actually one of my favorite things that they put into this exam. Minimizing base image footprints, like since security in Kubernetes is so vast, so to speak, it's not just in Kubernetes, we need to secure a Docker image. We need to make sure we're pulling the correct images. We have to, we can specify which registries we can pull from, not pull from, right? Because by default, Kubernetes pulls from Docker Hub for an image that might not be acceptable, especially in something like a private cluster. So we wanna verify that our workloads, anything that we're bringing into the cluster is signed, verified, and it doesn't have any vulnerabilities. And lastly, I think the biggest slide in the deck is monitoring, logging, and runtime security. These are a little bit more vague since they really are very broad. But yeah, so immutability, audit, logging, and performing analysis kind of take the core, the frontier where we wanna make sure that we understand how to diagnose things, so how we set up logs so that we know we can identify bad actors. Can we implement certain tools to look at runtimes and analyze different applications at runtimes or different applications that are requesting escalated privileges or things of that sort, if we wanna make sure that we have visibility into those. Okay, so moving into the section breakdown. So I'm gonna kind of just pick apart some of these sections and there's a bunch of questions that I will try to pick off as I go. So if I miss something, I will hit it at the end, just FY, don't worry too much. Okay, I get a bunch in here. So for cluster setup, the sort of six points for network policies, cube bench, securing Kubernetes components, Ingress objects, node metadata and minimizing access. Network policies did get a bump in 119, they now have more functionality. So you have default deny, default allow, more labels and selectors, functionality, and you also have IP blocks. So there's this to and from functionality that is worth getting acquainted with and really network policies are the core enforcement tool inside your cluster. So just in general, outside of CKS, it's worth understanding network policies, it's also worth understanding how to orchestrate an application by namespace so that you can then apply, these are back in network policies efficiently just from an organizational standpoint. Next, cluster benchmarks. So cube bench is a tool that's mentioned and it's worth also looking at the documentation that you're allowed for the CKS. Cube bench is a CNCF tool and it runs checks based on the CIS benchmarks. Now, a lot of tools, if you think about the time that you have for a question, the tools must be somewhat streamlined, right? We're not gonna spend 10, 20, 30 minutes on a test. So normally most questions are here's information, you have to know what to do with it, just understand what the tools are trying to accomplish and how you would secure the cluster after. So Ingress Objects, you will see in let's say some more scalable environments and maybe not scalable, it's the right word for it, but you'll see multiple Ingresses in a single namespace. There is an Ingress class that has come in. So it is a security issue with Ingress being misconfigured between various different Ingress controllers, just worth understanding the different Ingress objects, how to apply them, how to add encryption as well. And then Network Policies, I believe, yeah, already went over so that's a duplicate slide, but Minimizing Access, so this topic is fueled by previous security hacks that have exposed the Kubernetes dashboard and just general cluster setup checks. So if I think it was in 2017 or 2018, there's a bunch of clusters that deployed Kubernetes dashboard by default and that port, if you deploy it on a public cluster, it was general knowledge. I actually think it was Tesla that had this issue, but again, just minimizing access, understanding how to search through services and narrow down any bad actors. Moving into cluster hardening. So we have API access, we have RBAC, default accounts and Kubernetes updates. Again, API access all about authentication, authorization and admission controllers as well. One of the core enforcement mechanisms in Kubernetes is RBAC, right? So at a minimum, we need to understand how to implement roles, cluster roles, role bindings, how to search for them, narrow them, how to understand the different verbs and the additive permissions that RBAC has so that we are not setting defaults of a cluster admin or we're not giving service accounts for applications, the ability to like a cluster admin sort of permissions and the default permissions are basically very narrow and scope as to what we give the workloads that are running in our cluster. Like I said, default accounts are a huge issue. Kubernetes by default, obviously wide open and in terms of network, in terms of the defaults that are enforced. So really we wanna make sure that we understand some of the defaults that are out there and then we work to scale those back into the permissions that we need only for our application. So understanding how to implement different restrictions on users, groups, service accounts, understanding how to use the auth can I functionality. So it's really useful to be able to see and diagnose what the service account or what user account has what access to the cluster. And lastly, I touched on this already, but Kubernetes updates, business lagging behind on updates, I wouldn't say lagging behind. There are a lot of external forces at work when you upgrade something from like 115 to 116 and you wanna make sure obviously that things don't break. So it is a very tough process, especially when you get, you know, SLAs and uptime thrown in there. So just be aware and understand, especially just the general life cycle of Kubernetes, the cadence, how we want to move forward and upgrade and just as an organizational level, understand some different tools that can help you with that. All right, onto system hardening. So minimizing host OS footprints, which really kind of very broad, but I think comes as removing unnecessary packages, identifying and addressing open ports and shutting down any unnecessary services. Now very broad in scope. So I'm just gonna talk about some of the things that are documented. One of them is app armor. App armor profiles can be enforced on a per node basis and the documentation is in there for, you know, how to set up profiles, how to enforce profiles, how to bring them into Kubernetes. SecOmp is also mentioned as well. Really what we're doing is we're allowing teams more fine-grained control per node as to what is allowed on the node. So, you know, you can separate workloads and we could say this process specifically, this process specifically will be okay on this node but cannot run anywhere else, right? That's what we're trying to enforce with something like app armor. Okay, so security context. This is very core to the test and understanding it, especially because you can apply security context at a container level and at a pod level as well. And then really pod security policies in OPA are built on top for enforcing those core security context. So, you know, things like user IDs, G IDs, file system IDs, Linux capabilities, mounted file systems. We wanna get to the point where our containers are doing only what we tell them and they're not, they're not mutable. You know, they're not escalating privileges. They're not accessing anything like catnet rod, accessing any network privileges on the host. Just be aware of how those different functionalities play with each other as there might be, you know, things that we have to debug or isolate. So pod security policies officially do for deprecation, I believe in one to one and will be removed in one to five. So, this has kind of been in the works for a while, the deprecation, not sure where we're gonna move to an enforcement, I can see OPA on the horizon, which I think is also why it was mentioned in this test. Just know that it's an enforcement mechanism and really how we imply enforcement mechanisms in the cluster are through RBACs across namespaces and cluster permission. So, again, understand the general concept, understand PSPs, how they're applied and that they are a cluster level enforcement object. All right, moving on to microservice vulnerabilities. So again, with PSP due for deprecation, just what I mentioned, OPA may take a larger role as especially since there's quarterly updates to the test, to the exam, you could see OPA also taking more of a larger role in the exam, so to speak. Now, isn't that much documentation on the Kubernetes website or mentioned in the CKS? So it's worthwhile narrowing down what you would need to know because really everything that is in the exam can be accessed or the concept can be accessed through the documentation. And I mentioned this before Kubernetes secrets, understand the secret lifecycle, how to access, remove secrets, protect secrets from other objects that shouldn't necessarily be using secrets. MTLS, I'll get a little bit more to this at the end because there's a lot of questions so I want to narrow it down, but just understand how MTLS can be applied within objects, pod-to-pod encryption. It's, if you think of questions that could arise, they wouldn't be super complicated to the point where it's going to take you 20 minutes. So if you're thinking, oh, I need to put MTLS into an Ingress object or something like that, probably going to be simpler than you think. So obviously worth understanding and worth going through some examples, don't stress out too much over it. Container Runtimes, I saw a question about container runtimes earlier, earlier. Worth understanding container runtimes, especially because Kubernetes is basically going hands-off and saying we will support anything that follows the container runtime interface framework that has been set up. So you'll see other runtimes such as Gevizer, Cryo, again, was one of them. Rocket, I believe it's there, but kind of faded and obviously Docker. So there's a couple out there worth understanding them, but just the other thing too is understanding that we can have multiple runtimes on a single node and specify those runtimes as well, again, so that we can isolate workloads. Cata as well. My favorite section, supply chain security. So for supply chain security, we are talking about everything into the cluster, all the steps that you usually have any workflow. So we're talking reviewing Docker file content, Docker images. What is in the image? Are we requesting special privileges? Are we putting any files that should be in there? Basically make sure those base images are correct. So if we're pulling Ubuntu Latest, is that necessarily the best case? Have we internally as an organization vet that Ubuntu Latest is safe and without any issues? So again, maybe we pull an issue, we need to scan it, then we need to verify and put it into our repo, then we use it as a base image on top of our other applications. You need to be aware of all these things that are going into actually running the image as a container in Kubernetes. So again, very important. Allowing secured registries. So blocking images from certain container registries, just so that, let's say somebody gets access and they want to pull an image into your Kubernetes cluster. Well, if you have a private server and you've only set up so that images can be pulled from our private image repository, well, somebody can get in and they can't pull from their service. They have to figure out another way around it. So little things like that will help you in your fight against any malicious people in your environments. Analyzing Kubernetes workloads. So you can kind of see where this is going in terms of what they're trying to accomplish here. Basically you need to know the whole lifecycle so that if we say, hey, there's an issue in X, you know how to go and debug it or hey, there's an issue in a Kubernetes object, a Docker file in how these images are being pulled and how we're in the access into the cluster, those are sort of the things that you're gonna need to figure out and debug during the test. And image scanning is very core. Again, I mentioned it earlier. So they mentioned Trivi and you have Trivi documentation so you can scan containers for critical issues. It's worth understanding the container scanning applications that are out there specifically Trivi. It's very easy to use. You do have the documentation and then also know what to do with that. So let's say you use it and you find an issue, what do you do? How do you resolve those issues? And the last section. So we have monitoring, logging and runtime security. So we wanna monitor malicious activity. We wanna look at audit logs. We wanna understand how to make our containers immutable. And then we wanna look at audit policy as well. Not sure why that's there. That's not, that's just a general thing. I think I copied that, sorry about that. But anyways, so for audit logging, audit policy is really, audit policy and also the, let's say, creativity that you can set for your audit logging and audit policy really takes the center stage in Kubernetes, especially in 119. There are a lot of things that you can set by default at cluster startup so that you can then pull logs down and view any changes in your Kubernetes environment. So again, we can pull logs, we can format logs. We can set up where we want our log back end to be. So let's say we have a logging controller, like something like Fluent D that's installed on our control plan node. We can tell Fluent D to or Fluent Bit to look at a specific file path that has our audit logs. We ship it to our logging setup and then we can view it all through there and then we can also control the types of logs that we wanna see to that log back end. So worth understanding how to set that up, how to monitor it and the different functionalities that we can change. Immutability, so I've mentioned this concept a couple of times already. Container immutability. So we're talking about image that is unchangeable once it's built, which means no escalated permissions, no mounted file systems, no access to privileged Linux capabilities. We just want our container to do exactly what we tell it to do and not have the ability to change anything inside of that container. So understand immutability, understand which of your workloads aren't immutable as well so that you are basically putting annotations and notifying internally in your organization that these are somewhat more flawed workloads. They require certain privileges and that we will pay, so to speak, more attention to these workloads, right? All right, so there's a lot of questions. I'm gonna go through general tips. I'm gonna put some resources. I got five more minutes left and then I'm gonna do about 10 minutes in questions if I can. So general tips from me on taking this. Review the documentation. A lot of these questions can be asked by actually, by reading the documentation that's given to you when you sign up for the exam. The documentation is actually available before you sign up for the exam, but again, read the documentation. They give you all the resources. They give you the links that you're allowed to use. A lot of the stuff that I'm talking about right here is pulled directly from the Linux Foundation and it's very thorough. So when you get into the test, take a breath, drink some water. You're allowed a clear water bottle and read each question and read each question thoroughly. You will save a lot of time by reading and understanding what's being asked of you because if you skip and maybe you come back and you're like, oh, that's what was being asked, then you might have an issue. So just FY, read it, bookmarks. So my favorite thing to do for the CKAS is to bookmark resources. So I'll go through and I'll say, okay, well, this is a really good resource. I like this. I'm gonna bookmark it, maybe set up different issues. You're allowed two different windows open. So I have two screens. I had one for the test. I had one for basically anything that I was reading and you can copy paste back and forth as well. So the bookmarks are really useful because if I had an example come up or if I need to access documentation, I would just go, boom, click it. I'm right in the document documentation where I wanna be, I don't have to spend time searching through for something. Recording tasks. Now when I previously took the CKA, there was a notepad. I don't remember using the notepad functionality when I took the CKS, but there are flags. So every single question you can flag to return or not flag to basically say, hey, I think I answered this properly, right? I actually did the opposite. So I flagged the questions that I thought I got. And then at the end, when I get the last question, I look and I just go, boom, boom, boom, boom, boom. Okay, there's four questions that I didn't get. And I can kind of get a general sense of where I am point-wise too. So that was just my tip as to how I did it. One little kind of funky thing is if the exam refreshes, you lose those flags. So just an FYI. Yeah, so time is of the essence. Cue control cheat sheet. You actually have, it's by default, Cue control will auto complete in these environments now. So you don't have to spend the time doing that. Just hey, okay, tab, boom, Cue control, save yourself some time. I recommend being proficient in VI, at least enough to do basic editing as it's already pre-formatted for YAML files. So you don't have to worry about spacing. Just go in VI, use it. If you're doing the Cue control edit, it becomes a lot easier as well. And then again, pay attention to the question context that Cue control config, whatever the cluster is and which environment you're in. So you don't get a little tripped up. Yes, never write a YAML from scratch. If you've done the CK, you'll understand this dry run output it to a YAML file, edit it from there and apply it. The CKS actually gives you in some questions, not in every case, but sometimes they'll give you sort of just the generic template of a YAML file because they understand obviously, it used to be three hours now, they shortened it to two. We can't have somebody just writing and doing dry runs on every single question, right? Some of this stuff is just basic templates. They give you a template, but then you have to know how to apply it and what rules to set. And then I've mentioned this already, but when using an SSH or SSH into nodes, ensure that you exit from the node to the central node before you take on any other questions or use that Cue control config command. All right, lastly, resources because I've seen some questions about this as well. So I actually just use my own personal resources. So I put up the resources from my personal rebotes on the bottom there. I'll copy it into the chat as well after this, but that's what I did. A lot of that stuff was also somewhat pulled out from Walid. So he is a great CK and CKS as well. Study guide, great resource. If you want to get in touch, he'd be happy to help you. He's always in the Kubernetes ecosystem. He's in the CKS. Join us on Slack and just ping him. Obviously don't all ping him right now because then I feel like I'm telling everybody to go spam him, but he's a really good resource. And if you join the CKS on the CNCF Slack, the Kubernetes Slack, I'm in there as well. You can ping me with some questions and I'll be happy to help you without telling you too much, obviously. Killer SH, I've heard some good things about it, especially for the CK, CKID. I didn't use it. It's been recommended to me by other people. Worth checking out. I would definitely say that as much as you can kind of study for the CK a lot using something like MiniCube, the CKS is a little bit more because you actually are using other tools, going into nodes, looking at supply chain security. So there's more there. I'm hoping that as the year progresses, some other, like I think you to me came out with the course as well. So I'm hoping as a year progresses you get some better environments to study with. That repo that I set up for the Kubernetes security specialist guide, study guide, I deploy a Rancher and RKE cluster. So there's a whole walkthrough for deploying an RKE cluster in GCP. If you want a 119 cluster, just very simply made and you can like tear up and tear down. Again, the other thing though obviously is that the Kubernetes version you're using is set up with QBADM 119. So there are certain configuration differences between something like if you were to go use a cluster in GCP, right? We can't access the control plane node in cloud environments. So it is kind of a study gap I'd say. Yeah, that's all I have. So thank you. Now I'm going to, there's a lot here so I'm gonna get to as many as I can. So in the curriculum there's a topic about MTLS between pods. Do we have to expect a service mesh? If yes, which one? If you're using any sort of external tool, it will be mentioned in the documentation. That's all I'll say about that. I'm prepping for the CK. I just want to know the difference in percentage between the CKS and CK. I believe the CK is 66% and the CKS is 67%. But again, Linux Foundation documentation, they have it there. Don't quote me on those percentages. Which parts should we focus on the most? That really depends on where you are in your Kubernetes journey. So I'd say focus on all the parts. From my standpoint, it was the hardest Kubernetes exam out there and it requires more knowledge than just reading Kubernetes documentation and understanding the concepts. You have to actually apply some of these concepts and almost work with them in your day to day. So I actually almost want to give kudos to the people who are part of building this exam because I actually think that they made it as hard as it needed to be to force you to really understand what's going on. Any specific course, KillerSH? Yeah, I've heard a lot of people recommending that one as well. Udemy, they came out with a course. I was pretty early, so it's interesting to see how this course has moved into this year. If I get more, I'll probably recommend something in Slack, but I didn't need to use them just really up to you. I think it's worthwhile, especially if they can give you a proper environment to study in. IAM roles. Yes, I thought the use of IAM specific roles in the CKS topics was really weird. So what is meant by the IAM roles in system hardening? Are we interacting with AWS? No, it's Kubernetes environment. IAM roles are somewhat to make you understand, especially the enforcement mechanism through the cluster. So you have RBAC, but then you have IAM roles on top that are pushing RBAC, which are then enforcing something like a pod security policy. Just, I think, to get people's brains moving along the enforcement lines. Do you think it's relevant to dive deeper on Sandbox Runtimes, their installation? You don't have to install anything, I believe, I don't want to talk, because I didn't, you know, they shuffle the question, so I didn't have to have anything like that, but it's definitely worth understanding the different runtimes, understanding kind of what they can be applied for, and how we can secure workloads using different runtimes. Hopefully I didn't give away too much. I'm not, somebody's going to be in my ear like, hey, don't say that. So two-year validity, if only they made all sorts the same. Yes, I personally think, because I believe it's like three years, right, for the CK and two years for the CKS. Partially, I just think because security tools will change, like you've just seen, they basically came out with this, and then PSPs are being deprecated, so you're, you know, by the time I have to take this, again, PSPs aren't going to be a thing. You really need to kind of, it kind of pushes you to keep up with the ecosystem. Same way that they're trying to push cluster upgrades, take advantage of the new security, and if you're stagnating in security, you're behind kind of thing. It's my sort of approach to it. Any training available for the CKSS? Again, join the Slack channel for CKS. Get involved. There is killerSH Udemy. There's a bunch of curated repos that people have pulled a bunch of different resources from. Good question though. I believe you use Ubuntu. So during the exam, you're using Ubuntu 18.04, I believe. They'll quote me on that. Again, check out the documentation for a better answer as to what distribution you're going to be using on the test. PSPs deprecated on 21? Yes. Two days out, I'm not quite sure what's being asked there. Should be familiar with Linkerdee. Answer that one. So is there a must-know list of security tools? The CNCF uses CNCF tools. So understand the ecosystem and what the tools are trying to accomplish, right? So if you have a container scanner, if you have a runtime detector, if you have something that is policy enforcement on the node or policy enforcement in Kubernetes, understand what the tools are used for so that if you work in an organization and somebody comes and says, hey, we want to install StackRocks or we want to install like Aqua or something like that, that you understand what those applications are accomplishing and where the gaps are in your security ecosystem. Hopefully that answers your question. PSPs are being deprecated. Are they a big part of the cert? Yeah, any time there's an enforcement mechanism in Kubernetes, they are going to play a role in what we test for, right? If it's not PSPs, it's going to be OPPA or it's going to be some sort of other enforcement mechanism. Hopefully that answers your question. Are we accessing the tools QBench? I don't believe you can go to GitHub. So the question was, are we accessing, are we able to access tools in a GitHub repo? So QBench, for example, I don't believe so. So the only documentation you can use is listed in the Linux Foundation and just understand that they don't ask a question that you can't actually discern a decent amount of information from that documentation, right? Now, you have two hours. So if you're bookmarking something and you think, hey, I'll have enough time to read through this during the exam, you won't understand what you are bookmarking and the different applications and before you get into the exam. Are the app armor profiles second provided or should we write it? I don't want to give away too much, but you have to think about time and the documentation that's provided to you. You should know how to write profiles, how to enforce them, how to apply them, right? Like that's a general life cycle. How do we apply and secure our nodes? Again, important to know. Recommended training environment. Yes, so this is the toughest one and the question was, do I have a recommended training environment? I actually haven't used KillerSH, but I heard that they have everything that you need in terms of the other applications, the things like that that are installed. It uses QBDM and you need to be able to understand the components, how to configure them, how to restart them, how to secure them and those things. So as much as like my environment, I used a Rancher cluster to create it and then I went through basically everything in Kubernetes, there's more to the security ecosystem. So get an environment that gives you basically access to all of those different components. Waiting for the demo, no demo. I'm sorry, this is all slides and me rambling. So thank you again for joining, sorry, no demo. How much deep knowledge required in OPA for CKS? So again, documentation, find the things on OPA that will probably give you the answers to your question about how much OPA you need to know. Falco, yes, sorry, I forgot to mention Falco in these slides, thanks Pavel for mentioning that. Falco and Cystig I think are both mentioned, although I was kind of curious about Cystig, but Falco is a CNCF open source tool for runtime detection, you can configure it. The documentation is there, also worth knowing how Falco gathers runtime, is a runtime detection tool that will tell you all the information about things like escalated privileges and maybe some processes mounting a file system that shouldn't and things like that. So thanks for the reminder and Falco is definitely worth looking into. And I believe I have three minutes left, so I'm just gonna try to speed through this. With documentation is allowed during the exam, Linux foundation will tell you. It's like Kubernetes, like Falco, Second Op, App Armor, like all that stuff, it'll be there. Check it out. Could I please provide links? Sure, I will do that right after I'm done this, I'll go back in the slide and I'll copy all my links into there. I've cleared the CKA exam to get into jobs. Bronson, so great question. You've done the CKA exam and you wanna leverage that into a Kubernetes job. I would recommend getting involved in the CNCF ecosystem, getting on Slack, looking at projects, looking at how to deploy projects. Maybe it's like I deploy a Kubernetes cluster and then I install some CNCF components and I create a whole stack and then I save all that into GitHub and I use it as a profile to say that I have more than just a certificate, right? I always think the CKA is a good knowledge base to start, but then you have to actually apply a lot of these things into, if you wanna leverage it for a job, right? If I've been working in Kubernetes for a while and I wanna get into CKS, send to more security space, well, then I might, I already have existing Kubernetes knowledge that I can leverage to move into the security space. Just hopefully that helps. Can the bookmarks be non-CNCF sites? The bookmarks can only be what is allowed in that documentation. So it'll say kubernetes.io, that means you can bookmark anything on the kubernetes.io webpage. You're allowed to monitors or two browser windows. You're allowed two browser windows? You're allowed two screens. Yes, you're allowed two screens. I actually, I have three screens. I have like my laptop and two screens here and they just monitor all three screens. I recommend you using two screens actually. I just find it really useful then going back and forth between web pages. Which questions are harder or more weighted? No, I can't do that. I'm sorry, I don't think I can tell you which ones have more weight. Unfortunately, but CKS give you the same time, pressure feeling like the CK or CKD did. That's a great question. I thought the CKS, I think the time pressure mostly comes from the format when you first get in there. So I took the CK and I took it almost two years ago now and it was a little bit of a different environment. It's since been upgraded and there's more features and functionality that makes it easier to take now. I didn't find the exam. I thought the exam was actually really well weighted and that you were given enough time to go through all the questions. It really just comes down to how you navigate it. Do you read properly, read the instructions and really understand what's going on because some questions will have a couple of things that you need to do. And if you understand what's being asked, you'll know exactly where to go and what to edit and what to change and what to apply and what to look at. So it's more of a take a breath, understand and read before you act. That's what I'll say. All right, I'm gonna steal two more minutes because there's a bunch more. Yeah, sorry, no demo. Do I have an administrator for the CK? No, I don't but Willie does and I recommend going to the CK on Slack as well for the Kubernetes. There's a bunch of resources and people that will help you. Anything to be concerned about container runtime being changed to Docker? No, I'm not worried at all about that. I think it's a little bit overblown. Can you copy the links from last slide? Yes, I will. Can I share my bookmark list? No, I will not do that. I'm sorry. I can't be given away stuff like that. Falko plus audit events. Yep, that's also worth knowing Falko and auditing events. How do we join the CKSS on Slack app? If you join a workspace, join the Kubernetes workspace on Slack. I'm sure if you go to Linux Foundation, they have a bunch of links there too for all of their different environments. Yes, the way the questions appear on screen can kind of be a little nerve-wracking sometimes. Can we complete these questions under six minutes? Yeah, thank you. That's a great question. Time, so you do only have so much time, right? So if you read a question and you think, oh, this is gonna take 20 minutes to do, you read it wrong. Most of these questions can be done in, honestly, two to seven minutes. It just really comes down to what you spend the time on and your workflow. So with that, I'm going to wrap it up. If you have more questions, I'll be in the CNCF Slack. I'm going to copy the, basically all of this, these resources, into the chat real quick. Hopefully that's in there for you guys to check out. And you can ping me in the Slack channel if I can get a link or go to Links Foundation, they definitely have it there. But the Kubernetes Slack channel, I'm in there. I'm in the CKS, CK, CKAD, wherever, send me a message. I'll be happy to answer any questions. So thanks to the Links Foundation for having me. I like talking about this. So, and really kind of pushing security forward. So thanks again for having me. And yeah, ping me anytime with your security questions. Thank you so much, Michael. And as you can see, the links that he provided are in the chat window. So everyone should be able to grab those there. But thank you again, Michael, for your time today. Thank you to all of our participants who joined us. The recording will be on the Links Foundation YouTube page later today. So check it out. And we hope you can join us for our future webinars. Have a wonderful day.