Intro to Certified Kubernetes Security (CKS)

0:00[AUDIO LOGO]

0:11Hi, guys, my name is Trevor Sullivan.

0:13And welcome back to another CBT Nugget skill.

0:16In this skill, we're going to be exploring the Certified

0:19Kubernetes Security certification.

0:22And we're going to go through, very quickly,

0:25some of the different topics that you're

0:27going to need to be familiar with

0:29and probably be expert level at with in order

0:32to pass the Certified Kubernetes security exam.

0:36If you are brand new to Kubernetes,

0:39I would strongly encourage you to start out

0:41with the other certifications that

0:44are available for Kubernetes.

0:46So there is the Certified Kubernetes Application

0:49Developer or CKAD.

0:51And then, there's also the Certified Kubernetes

0:54Administrator as well, the CKA.

0:57And both of those are much more easy to pass.

1:00There's a lot more fundamental concepts in Kubernetes,

1:03just things about setting up clusters, deploying application

1:07workloads, setting up role-based access control,

1:10and things like that are pretty straightforward.

1:13Once you start to dive into purely the security

1:16side of Kubernetes, you're going to be looking

1:19at a lot more back-end configuration stuff, that you

1:22don't typically see with the Certified Kubernetes

1:26Administrator or the CKAD application developer exams.

1:30So the Linux foundation here and, more specifically,

1:34the Cloud Native Computing Foundation

1:36that is working actively on the Kubernetes project

1:38and providing oversight for Kubernetes

1:41and a variety of the other Kubernetes tools

1:44that are out there in the open source ecosystem,

1:46they've got this guide that talks

1:49about some of the different things

1:50that you'll want to be familiar with.

1:52Some of the different topics that

1:54are going to help to prepare you to take and pass

1:57the Certified Kubernetes Security, or CKS, exam here.

2:02Now, there's a few high level domains and competencies here

2:05that you're going to have kind of different biases on.

2:08So some topics are going to be heavier hitting

2:11on the CKS exam.

2:13And other topics are going to be a little bit lighter weights,

2:16but are still going to be important things to understand.

2:19One of the nice things about starting off

2:21with the CKA, the administrator or the CKAD,

2:24the application developer exams for Kubernetes

2:28is that those are going to kind of pave

2:30the way for you to kind of build up towards Certified Kubernetes

2:35security, rather than just if you're brand new to Kubernetes,

2:39biting off more than you can chew all at once.

2:42And then, just going straight for the security topic.

2:44It is just going to be a lot more gradual to start off

2:48with CKA and CKAD.

2:49And then, once you've got that foundational knowledge

2:53of how to deploy workloads, and do some basic configuration

2:56in Kubernetes, and things like that, then you're really

2:59going to get into the CKS.

3:01Now, I've tried with the CKA and the CKAD certification courses

3:05to go a little above and beyond.

3:08So you're not necessarily going to have

3:10to watch the entire course just to pass the exam.

3:13But I've actually added a lot of other value

3:16added tools that you'll probably come across

3:18in the open-source ecosystem surrounding Kubernetes.

3:21And I've actually done the same thing with CKS as well.

3:25So there are going to be some tools within this CKS training

3:28course, that probably won't appear on the certification

3:32exam.

3:33But by gaining familiarity with those tools

3:36and just getting comfortable.

3:38The more time that you spend with Kubernetes,

3:40the more different types of tools

3:41that you're using with Kubernetes,

3:43it's going to better prepare you for actually

3:47passing these exams once you get to the point of taking it.

3:51So we're going to be talking about these different domains

3:54and competencies.

3:55And I've actually already recorded

3:57a lot of the training for CKS.

3:58I'm not quite done with it as of this recording.

4:01But I kind of saved this for the end,

4:03so that we could kind of build out the training content

4:05and see where things kind of evolved to.

4:08And then, I came back and recorded this introductory one.

4:11So I'm actually going to be building off

4:13of some of the experience that I've gained just

4:16by building out the training for the CKS training course

4:19here at CBT Nuggets thus far.

4:22So at a high level here, the domains and competencies,

4:25you're more than welcome to check out this content

4:27over on the Linux Foundation site

4:29or on the Cloud Native Computing Foundation site.

4:32They have a lot of the same information on both of them.

4:35But under domains and competencies for CKS,

4:38we're going to have some kind of fundamental things

4:41that are going to overlap a little bit with the CKA course,

4:44where you've got cluster setup.

4:46It's going to be really important for you,

4:48whether you're an administrator, an application

4:50developer, a DevOps engineer, a security engineer,

4:52it doesn't really matter what role you have.

4:54If you're going to be actively working with Kubernetes,

4:57it's really going to pay off for you to get experience just

5:01setting up a Kubernetes cluster from scratch.

5:04And so when we talk about cluster setup,

5:06we're talking about everything from provisioning a Kubernetes

5:09cluster to just high-level familiarity

5:12with the different Kubernetes distributions

5:14that are available out there.

5:16There's lots of different Cloud-managed services

5:19from the likes of Digital Ocean, for example.

5:23They provide a managed Kubernetes service.

5:25So you can literally just come in here

5:26and say, create me a Kubernetes cluster.

5:29Or you can go into the LiNode platform

5:31and say, create me a Kubernetes cluster.

5:33You can plug-in a couple of lightweight details,

5:36give it a name, give it a few worker

5:38nodes to join to the cluster.

5:39And, bam, you are good to go.

5:42Also, the major Cloud vendors like Amazon Web Services

5:45and Microsoft Azure have their own managed Kubernetes

5:49distributions as well.

5:50Also, Google Kubernetes Engine.

5:52So all the major Cloud vendors have their own distributions.

5:55However, the reason that I tend to like

5:58more of the kind of smaller vendors,

6:00more of the niche vendors like LiNode, and Digital Ocean,

6:03and Vulture even, they are another vendor out there

6:06that has a managed Kubernetes solution.

6:08The reason that I like these smaller Cloud vendors

6:10is because they really specialize

6:12a lot more than the major, the big three Cloud vendors, Azure,

6:16AWS, and Google Cloud.

6:17And so they're able to provide easier to use APIs.

6:21They're able to provide nice CLI tools that

6:25are just really simple to use.

6:27They also provide just a nicer web user interface.

6:30So if you're just going in and using the web interface

6:32to manage your account with LiNode or Digital Ocean,

6:35it's just a lot simpler of an interface.

6:38And there's a lot fewer moving parts.

6:40Whereas, if you're using one of the major Cloud vendors

6:43to provision and manage your Kubernetes cluster,

6:46yes, on the positive side, you do

6:48have a lot more customizability over the network configuration

6:52and the node configurations.

6:54You have a lot more selections to choose from in terms of what

6:57virtual machine types you want to join to your cluster.

7:00But I personally, for my particular use-cases

7:04of just learning about Kubernetes,

7:05getting familiar with it, and being able to rapidly provision

7:09and de-provision clusters, I personally

7:11get a lot more value out of these smaller Cloud vendors,

7:15because they really do focus on the user experience.

7:19Their web consoles are just really

7:20nice and pleasant to use.

7:22And another benefit here is that these smaller niche

7:25Cloud vendors actually tend to keep up-to-date with managed

7:29Kubernetes versions a lot better than the major Cloud vendors.

7:34When you get into the large Cloud vendors like Microsoft,

7:36and Amazon, and Google, they tend

7:39to lag behind on Kubernetes versions a bit more

7:43because the fact that they're larger companies means

7:45that there's a lot more rigorous testing that they have to do.

7:48There's a lot more edge cases that they have

7:50to plan for during upgrades.

7:52They have to just consider a lot more variables

7:56than what these smaller Cloud vendors have to worry about.

7:59And so because they do focus a little bit more

8:02tightly on their niche area within the Cloud industry,

8:05they are able to move much more rapidly.

8:08And they also have very competitive pricing plans

8:11as well.

8:12And they're very straightforward pricing plans.

8:14That's actually another benefit of using

8:16these smaller Cloud vendors to provision clusters

8:18is that their pricing is just more straightforward.

8:20A lot of people get confused when

8:22you talk about pricing of AWS.

8:24Do you have to pay for this?

8:25Do you have to pay for this?

8:26Do you have to pay for this?

8:27And with these smaller Cloud vendors,

8:28their pricing is really transparent.

8:30It's simple, straightforward.

8:32And so if you're trying to do cost planning

8:34for your organization or your business unit,

8:37then these smaller Cloud vendors do provide a lot of value

8:41in that regard.

8:42Now, aside from the Cloud vendors

8:44that provide managed services to deploy a Kubernetes cluster,

8:48there's also tons and tons of different Kubernetes

8:51distributions available.

8:52My personal favorite is K3S from Rancher Labs.

8:56And there's a bunch of others as well.

8:58There's Minikube.

9:01So this is kind of just a mechanism

9:02that you can use to rapidly spin up a cluster.

9:05There's also Kubernetes in Docker or the Kind software.

9:10This is yet another distribution that

9:11allows you to run Kubernetes in a Docker container.

9:13And then, you also have things like MicroK8S from, I believe,

9:18it's canonical.

9:19This is just another distribution of Kubernetes

9:21that has some pre-installed components inside of it.

9:24And there's a whole bunch of other distributions

9:26of Kubernetes.

9:27There's K3D, K0S.

9:29And I can't think of all the others off the top of my head

9:32right here.

9:32But as you can see, there's just a lot

9:34of different distributions of Kubernetes

9:35that allow you to either use a Cloud vendor for the managed

9:38side of things.

9:39Or if you just want to spin it up at home, in your home lab,

9:42or just in on a virtual machine that's running in some Cloud

9:45vendor, it doesn't really matter which Cloud vendor,

9:47if you don't want to use the managed offerings,

9:49there's lots of self-managed solutions

9:51that you can use to spin up clusters as well.

9:54So knowing how to set up a cluster

9:57and do some basic configuration on it

9:59is going to be a really important concept, regardless

10:01of which certification you're getting.

10:03But as a security engineer, it really

10:04helps to know that kind of thing.

10:06Because then, you can start to learn the different knobs

10:09and levers that you have control over in order to customize

10:13your Kubernetes deployments.

10:14I hope this has been informative for you.

10:16And I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hi, guys and welcome back.

0:12So in the last video, we talked a little bit

0:14about the different certifications

0:16that are available from the Cloud Native Computing

0:19Foundation.

0:20And I wanted to just continue talking about some

0:22of the different domains and competencies here

0:25that you're going to need to know for the Certified

0:27Kubernetes security exam.

0:29And, again, keep in mind that I've

0:31recorded already a lot of the training content

0:33for this course.

0:35And so this is just, I'm just pulling from my experience

0:38that I've got while I've been preparing

0:41the content for this course and just

0:43trying to give you a high level overview over some

0:45of the different topics that you're

0:47going to want to know about.

0:48So let's move on from cluster setup

0:51and focus a little bit more on Cluster Hardening and System

0:54Hardening.

0:55So for Cluster Hardening here this

0:56is going to be covering topics like restricting access

0:59to the Kubernetes API.

1:01As you probably know working with the API server

1:04is a really important concept because pretty much everything

1:07that you do to manage Kubernetes from a resource management

1:10perspective is going to be done through the Kubernetes API

1:13server.

1:14Granted there is a lot of back end configuration

1:17that you can do as a security engineer

1:19on the actual Kubernetes components themselves.

1:22So you can customize different command line arguments

1:25on things like the scheduler and the controller manager

1:28and the API server itself.

1:30And we actually do talk about some of those things

1:33like how to set up audit logging, how

1:35to work with Kubernetes events to monitor

1:38the state of the cluster and things like that.

1:41The audit log is actually a really important concept

1:43because it shows you what is going on behind the scenes.

1:46And it allows you as a security engineer

1:50the maximum observability over what

1:52different users of your clusters are actually doing inside

1:56of those clusters.

1:57So you can get access to basically the raw API

2:00calls that are being made to your Kubernetes API server

2:03so that you can detect any potentially malicious activity

2:07and to just keep tabs on what people are doing.

2:09And then this is really important for incident

2:12response.

2:13So if you ever run into a security incident

2:15and you need to do some investigative work to figure

2:18out how a malicious actor gained access to an application

2:22or gained access to a cluster or a node within the cluster,

2:26then having access to things like audit

2:28logs, in addition, to node level logging,

2:31is going to be really important for you

2:33to have all the necessary data to investigate those incidents.

2:37So the audit logging feature in the API server

2:40is actually a really important concept behind that

2:42and also being able to use role based access control to limit

2:47the different operations that users

2:49are able to perform against the Kubernetes API server as well.

2:54There is actually one other thing related to the Kubernetes

2:56API server that I wanted to talk about,

2:58which is a little known feature called API Priority

3:00and Fairness, and I actually have

3:02a skill that goes into depth on how this feature actually

3:07works.

3:07But it actually allows you to assign

3:10what's known as fairness rules or I forget

3:13exactly what the resource name is called but it's basically

3:15just a way for you to set up a rule in your Kubernetes cluster

3:19that allows certain users depending

3:22on certain attributes like where the traffic is coming from,

3:25or who the user is, or what groups they're a member of,

3:28and it allows you to control and prioritize network traffic

3:32going to the API server rather than just leaving it

3:37to the whims of the default configuration of the cluster

3:40to determine who's going to have priority.

3:42So if you have some kind of outage situation

3:45where your API server is being hammered by a malicious user,

3:49then you can prioritize administrative traffic

3:52from trusted users.

3:53And so understanding how to use that priority and fairness

3:56feature, especially in large enterprise environments,

3:59is going to be an important topic around ensuring that you

4:04have continued high availability and accessibility to all

4:07of your Kubernetes clusters.

4:10Now, there's also some stuff here around keeping Kubernetes

4:14up to date as well.

4:15Now keeping Kubernetes up to date

4:16is actually really, really easy if you're

4:18using one of these managed cloud vendor solutions

4:21because they actually allow you to go into your clusters,

4:24and basically just initiate an upgrade.

4:26Whereas if you're using a self-managed distribution

4:29of Kubernetes like k3s or any others out there,

4:33then they're going to have their own separate upgrade processes.

4:36And hopefully they have good documentation as k3s does,

4:39on how to actually go through and perform version upgrades

4:43on your cluster.

4:45Now, one of the reasons that it's really important

4:47to understand how to properly upgrade Kubernetes

4:50is because Kubernetes has a very rapid development cycle where

4:54there's new features that are constantly

4:55being added, or changed, or sometimes removed even.

5:00So to give you a recent example, in Kubernetes version 1.25,

5:05the Pod Security Policy or PSP feature

5:09was actually completely removed from Kubernetes.

5:12And so anybody who had been previously using

5:14that feature is going to potentially experience problems

5:18when they attempt to provision Pod security policies

5:22if they upgrade their cluster from, let's

5:24say, 1.24 and earlier versions where

5:27it had been deprecated but still available

5:30as an optional feature.

5:31And they upgrade their cluster to 1.25,

5:33that could potentially cause a breakages

5:36for the users of that cluster.

5:38And so by properly understanding how to upgrade the cluster

5:41to do the appropriate planning steps

5:43is going to be a really important concept

5:45for you to understand from a security perspective.

5:50Let's also talk about system hardening here as well.

5:52So keep in mind that if you are deploying Kubernetes clusters,

5:56you don't just have your master nodes.

5:58The master nodes are arguably one

6:00of the more important components just because they

6:03run your backend API server and the controller manager,

6:07which basically manages state on the cluster.

6:09It's also got your etcd key value store,

6:12it's also got things like your scheduler

6:15that determines which nodes in the cluster to run pods on.

6:19And so the backend master servers

6:21are, of course, very important.

6:22But then on the worker operating system side,

6:24you also need to ensure that the worker nodes are secured

6:28from a logging standpoint, you need

6:31to make sure that they have enough capacity

6:34available to run the different application

6:36components on your cluster.

6:38You also need to ensure that there

6:39is things like quotas in place to prevent users

6:43from competing for access, or taking up

6:45too much access on a cluster for the different capacity of CPU

6:50and memory that's available on those worker nodes.

6:53And so understanding things like quotas in Kubernetes

6:56just from a resource management perspective

6:58is a really important concept.

7:00But we also want to make sure that the operating

7:03system itself has been secured as well.

7:05So you're not going to want to go on to these operating

7:08systems and just install tons of software packages onto them.

7:11And that's going to really open up your attack

7:14surface on those worker nodes.

7:15So generally speaking, you're going

7:17to want to make sure that the operating systems

7:19on those nodes are up to date.

7:21But you don't want to be installing a lot of software

7:23on them, and opening yourself up to potentially new

7:26vulnerabilities that may exist in some of those third party

7:30software packages that you install.

7:32If you do find yourself in a situation

7:33where you feel like you need to install something

7:35on those host operating systems for your Kubernetes worker

7:39nodes, then just be carefully considering that decision.

7:43And if you need to, then maybe just

7:45spin up a separate virtual machine outside

7:47of your Kubernetes cluster to run whatever

7:49it is that you feel you need to install

7:51on the nodes themselves.

7:53After all, if you do need to run something like a logging agent,

7:57or a metrics agent, or some other kind of security

8:00agent on your worker nodes, you can do that

8:03by creating something in Kubernetes called the daemon

8:05set.

8:06And the daemon set is basically a resource

8:09you create in Kubernetes that will actually

8:11spin up a container on each node inside of the cluster.

8:15It'll create a pod for each node in the cluster.

8:17So when you join new clusters or new nodes to the cluster,

8:20it's automatically going to provision

8:22whatever that logging or metrics agent is onto that new node.

8:25And when you delete a node from the cluster,

8:28then Kubernetes is basically just going

8:30to kill off the pod that belongs to that particular node

8:34automatically, so that you don't have

8:35to worry about managing those individually.

8:39So understanding just the host operating system management

8:42process or the worker nodes is also

8:44a really important concept.

8:46From an IAM roles perspective, this is--

8:49basically what we're talking about here

8:51is limiting the permissions on the different identities

8:54in Kubernetes.

8:55So if you create service accounts for your applications

8:57or if you create a service account for somebody

8:59to access the Kubernetes cluster with a token,

9:02then you want to make sure that you're not

9:04giving those users, those identities, in your cluster

9:07too much access to the cluster itself.

9:10Generally speaking, different development teams

9:12are going to have access only to namespaces within Kubernetes

9:16that they specifically need access to.

9:18And so you don't want to give, let's

9:20say, a developer on some random dev

9:22team, cluster admin access if you

9:24have five or 10 different dev teams that

9:27are using the same cluster.

9:28Because that one lone developer that's

9:30part of a single dev team could then

9:32have a very significant impact if they accidentally

9:35do something that damages other application components

9:39that other development teams are responsible for.

9:42So using that least privilege model

9:43to ensure that there are not too many permissions

9:46being granted to the different users of your cluster

9:49is really important.

9:50So role-based access control.

9:52Also minimizing access to the external network.

9:56So this is where you basically want

9:57to use things like firewalls and network policies

10:01and third party network policy plugins like Cilium and Calico

10:05as well to control access from your pods that

10:09are running inside of your Kubernetes cluster,

10:11to the external networks.

10:14Now, as I mentioned, Cilium is a really nice network policy

10:18engine here.

10:19I actually just recently created some training

10:21that covers network policy with Cilium.

10:23It also has a lot more advanced features as well,

10:25some higher layer, things that allow

10:27you to inspect HTTP requests and DNS requests,

10:30and things like that.

10:31But it also supports just the built-in network policy

10:34in Kubernetes that allows you to lock down the network

10:37traffic in your Kubernetes cluster

10:39to make sure that your pods aren't able to reach out

10:42to IP addresses on the internet that they shouldn't be reaching

10:45out to.

10:46And in the opposite direction, from an ingress perspective,

10:50ensuring that other malicious users on the internet

10:53are not able to attack certain applications

10:56that are running on your cluster.

10:58So if you've ever been familiar with something

10:59like Fail2ban, for example, that's

11:01an application that runs on Linux that basically

11:04automatically bans IP addresses if it

11:06detects malicious activity coming from them.

11:08So you can think about applying those types of rules

11:11to your cluster, but you're doing it at the pod level

11:13rather than at the host level.

11:16So, anyways, network policy is going

11:17to be a really important concept for you to understand

11:19in Kubernetes for Certified Kubernetes security,

11:22as well as firewalls at the host operating system,

11:26at the VPC, or software defined networking level as well.

11:31So there's also one other utility,

11:33which is something like AppArmor set comp,

11:35these are just built-in components in Linux

11:38that allow you to lock down access to the Linux kernel.

11:41These are pretty advanced features,

11:44so I wouldn't go too deep on these particular topics.

11:47But you are going to at least need

11:49to be familiar with things like AppArmor,

11:51Set Comp, and what Cisco calls in the Linux Kernel R

11:54so that you'll be able to understand

11:56those concepts if they do come up on your take of the CKS

12:00exam.

12:01I hope this has been informative for you,

12:02and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hi, guys and welcome back.

0:12So in the last video, we talked a little bit

0:14about cluster hardening as well as

0:17operating system hardening for the worker nodes that

0:20are joined to your cluster.

0:21Let's move on a little bit and talk about Microservice

0:24Vulnerabilities here.

0:26This is a 20% of the exam here.

0:28So this is going to be a pretty significant topic

0:30on the Certified Kubernetes security exam.

0:34One of the first topics that is covered under minimizing

0:37Microservice Vulnerabilities is to set up

0:40the appropriate operating system level security

0:42domains using things like PSP.

0:45Keep in mind that Pod Security Policy is actually deprecated

0:50and that's been removed in I believe Kubernetes 1.25.

0:53So PSP is an agent topic but you are still

0:57going to want to be familiar with it

0:59because if a question pops up on the CKS exam

1:03or and maybe your organization has older cluster versions that

1:06are still running in its environment,

1:08then you'll want to at least have familiarity

1:10with what a Pod Security Policy is

1:13and how it applies how it associates two pods

1:16within your Kubernetes cluster.

1:18So even though it's a deprecated feature,

1:20spend some time with it, spend some time playing around

1:23with Pod Security Policy resources.

1:25Yes, you're going to get those warnings from CUBE kubectl that

1:28will pop up saying that, hey, the PSP feature has

1:31been deprecated and it's going to be removed in the future.

1:33But that's totally OK, because again

1:36you probably just want to know that for the exam.

1:38And we have a skill in this course

1:40that's going to talk about Pod Security Policies.

1:42Also the feature that's replacing Pod Security Policies

1:46is called the PSA or Pod Security Admission

1:49controller in Kubernetes.

1:50So that's the new version of PSPs so to speak.

1:55It's a little bit less customizable than PSPs

1:58because it has built in tiers that it allows you to apply

2:02to your Kubernetes pods.

2:04But PSP and PSA are the new security features

2:08that will allow you to lock down access to your Kubernetes pods

2:12so that your users of your cluster

2:14are not able to spin up privileged containers

2:17or containers that are allowed to have privilege escalation

2:22or having certain permissions set up on them.

2:25We want to make sure that those types of things

2:28are blocked so that developers are not deploying

2:30privileged applications that could then be compromised

2:33by an attacker much more easily than a pod

2:37that has the appropriate security

2:39context being applied to it.

2:41So make sure you spend some time with that.

2:42Also OPA here is short for Open Policy Agent.

2:46So an OPA is kind of a generic framework that

2:49allows you to create what are known as policies

2:53and it doesn't just apply to Kubernetes.

2:55OPA is actually a generic utility

2:57that allows any application out there to basically send

3:00a payload to it, and then can actually

3:03write these customized rules inside of OPA.

3:06OPA will basically do a determination

3:08whether that action should be allowed or rejected,

3:12and then it'll send the response back to the caller.

3:15So OPA gatekeeper is a specific open source project

3:19within the OPA ecosystem.

3:21There's also another utility called Conftest as well.

3:25That's an open source project that uses the same language

3:28that OPA gatekeeper uses to write these different rules,

3:33these policy rules.

3:34The language is called Rego and it's

3:36based on the Golang syntax.

3:38And so OPA gatekeeper is this generic multipurpose policy

3:43engine that does integrate with Kubernetes so

3:46that you can create these customized policies.

3:49And then you can basically determine

3:50if certain API requests whether it's to the Kubernetes API

3:54server, or to your own customized application

3:57that you've deployed onto a Kubernetes cluster, or even

4:00an application that you haven't deployed on Kubernetes,

4:02maybe you've just deployed it onto a virtual machine

4:05just bare metal so to speak.

4:07Or maybe just using Docker just a standalone Docker agent

4:11rather than using Kubernetes.

4:12OPA has a really broad application as far

4:15as policy application goes.

4:17It's very customizable, it's very general purpose.

4:20And so OPA is not just specific to Kubernetes,

4:23but it is a very powerful policy engine.

4:26Now one of the policy engines that

4:28is not listed in this particular rubric

4:31here is something known as Kyverno.

4:33So Kyverno is a third-party open source application

4:36that is also a policy engine.

4:39And what's really powerful about Kyverno

4:40is that it actually plugs into another very important concept

4:44in Kubernetes known as admission control.

4:47Admission control is I would say a security related feature.

4:51It's primarily security related because it basically

4:54allows you to plug into the Kubernetes API server.

4:57You can actually intercept API requests

4:59that your end users are sending to the cluster.

5:02And then it allows you to make a policy determination very

5:06similar to what OPA gatekeeper is capable of doing,

5:08but it's specific to Kubernetes.

5:10And it allows you to accept, mutate, or reject

5:14API requests that are coming into your API server

5:17in Kubernetes.

5:18And then based on the request parameters

5:21you can basically say, OK, this user is allowed to do this

5:24or they're not allowed to do this,

5:25or they're allowed to do this but I'm

5:27going to modify something about their request

5:30before I actually pass it on.

5:32So admission control and kyverno in particular

5:36are really powerful features, really powerful applications

5:39that you can use within Kubernetes.

5:42Admission control is really more of a feature of Kubernetes.

5:45And kyverno is a third party application

5:47that you actually install into your cluster.

5:49But what's really nice about kyverno,

5:52and we can actually head out to the kyverno website right here,

5:54is that they actually have this pre-built list of policies here

5:58that allow you to control certain aspects

6:01of your cluster.

6:02So when it comes to things like enforcing certain registries

6:07to be used for your container images,

6:10or whether it's enforcing certain security context

6:13configurations for your pods, or whether it's adding image poll

6:18secrets you can access your private container image

6:21registries, or, let's see, adding certain labels,

6:26maybe you want to enforce that.

6:27Maybe you want to enforce adding network policies

6:29to new namespaces that are created on the cluster.

6:32There is a huge list in Kyverno here of different policies

6:36that have already been built by other people.

6:39And this is basically just a registry

6:41of these pre-built policies that you can go through,

6:43you can select which of these policies you want to apply.

6:48Let's take a look at Add image poll secrets here.

6:50And then you can actually deploy this cluster policy

6:53as a custom resource inside of your Kubernetes cluster

6:56once Kyverno has been installed.

6:58And then this policy, Kyverno will actually

7:01enforce the rules that are defined inside of this policy.

7:05So Kyverno is a little bit more specific to Kubernetes

7:08as compared to OPA Gatekeeper and NETCONF Test,

7:13but it-- because it is more specific to Kubernetes,

7:16I would say that it's a bit easier

7:17to use than OPA Gatekeeper.

7:20And so I would really encourage you to take a look at Kyverno.

7:23I actually really like Kyverno because it's really

7:25well supported, it's got a lot of development effort going on

7:28behind it.

7:29It's very easy to install.

7:31And the fact that they provide this registry

7:33of pre-built policies for Kyverno, just

7:36makes it that much easier to implement inside

7:39of your environment.

7:42Now managing Kubernetes Secrets is

7:43going to be another major topic of microservices.

7:46So when we talk about secrets in Kubernetes,

7:48Kubernetes does have a built-in resource

7:50called a secret resource type.

7:52Unfortunately, Kubernetes doesn't really

7:54encrypt or do any advanced protection of those resources,

7:59aside from applying role-based access control

8:01rules to those resources, because they

8:03are a secure resource, just like any other resource

8:06in Kubernetes.

8:07But Kubernetes, all it does is it base 64 encodes your secrets

8:11and then it stores them inside of the etcd key value store.

8:14And that's about it.

8:15So if you really want an enterprise-grade secrets

8:18solution, you're probably going to want to look

8:21to a third party solution.

8:23Of course, the major cloud vendors

8:25out there provide managed services for secrets.

8:28So if you're using Amazon Web Services,

8:30then you've got a AWS Secrets Manager,

8:32you've got AWS Parameter Store which

8:35allows you to encrypt secrets with AWS Amazon KMS Key

8:39Management Service.

8:41There's also Microsoft Azure Key Vault

8:43if you're using the Microsoft Azure Cloud platform.

8:45And I'm sure Google Cloud probably

8:47has something similar to that, although I'd

8:49have to look up exactly what they

8:51call that particular service.

8:53Now another nice thing about secrets

8:55is that there's actually an open source solution out there

8:59from a company called HashiConf.

9:00And they produce this open source tool called Vault.

9:04And you can actually run Vault on your Kubernetes cluster.

9:08It integrates very nicely.

9:10And so I've actually created some training that

9:12shows how to set up Vault on your cluster,

9:14to unseal your Vault. And then make those secrets that

9:18are stored inside of your HashiConf Vault system

9:20available to the application pods that are running

9:23on your Kubernetes cluster.

9:25So Vault is pretty well documented.

9:27HashiConf generally does a pretty good job

9:29with their open source tools and their documentation

9:32for those open source tools, so I really

9:34encourage you to check out Vault. Also pod

9:39to pod encryption with mutual TLS.

9:41The little m there is short, short for mutual TLS.

9:44This is an important concept because by default

9:46when pods are communicating with each other on the cluster

9:49network internally to Kubernetes,

9:51those pods are not going to be encrypting

9:54network traffic between them.

9:55And if an attacker was somehow able to intercept

9:58network traffic that was going from pod running on host number

10:01one, to a pod running on host number two,

10:04then that attacker could inspect that network traffic,

10:08and use that network traffic to grab an authentication token,

10:12and then use that token to perform

10:14unauthorized tasks in a system.

10:16Or they could modify those requests

10:18as they're being sent between different services.

10:21And those are just things that we want to avoid.

10:23And by implementing mTLS by way of what's

10:26known as a service mesh solution in Kubernetes,

10:29it makes it very, very easy to automate the certificate

10:32management for mTLS.

10:34If you'd try to do manual certificate management for mTLS

10:37or you tried to write your own system to do that,

10:39there would be a lot of complexities

10:41that you would have to plan for.

10:43And so service mesh solutions like Open Service Mesh

10:45or Traefik Mesh or Istio, and many other service mesh

10:50solutions out there will actually

10:51automate the process of that certificate management

10:53for you so that you can get that true pod to pod

10:56security between your different pods

10:59running across different hosts, different worker

11:02nodes inside of your Kubernetes clusters.

11:04So that's really the main topics around Microsoft service

11:07vulnerabilities that you'll want to be aware of for CKS.

11:11I hope this has been informative for you,

11:12and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hi, guys and welcome back.

0:12So in the last video, we talked about some of the topics

0:15that you want to be familiar with in the Certified

0:18Kubernetes Security exam as it pertains to microservice

0:21management and vulnerabilities.

0:24Now let's shift gears a little bit and talk

0:26about supply chain security.

0:28So when we talk about the software supply

0:30chain in general, what we're typically talking about

0:33is getting your application source code

0:36that you're writing.

0:37It could be a Python application, Golang, web API.

0:41It could be some backend component

0:43that you're writing in Ruby, or PowerShell,

0:46or some other language out there.

0:48But basically you've got your application source code, right?

0:50And then typically you go through some kind of testing

0:53process, you've got unit testing,

0:56you've got integration testing, you've

0:58got performance testing, load testing that you need to do.

1:01But basically in order to do certain types of testing

1:03and deployment on that application, if we do

1:05want to do load testing on the app,

1:07then generally we would need to package up that application

1:10first and then deploy it to some environments

1:12so that we can actually run the load tests on that environment.

1:15Or if we're deploying it to a production environment,

1:18or to a QA environment, or manual QA processes

1:22where actual QA users are actually

1:25interacting with the application themselves using their keyboard

1:28and their mouse to actually play around

1:30with a web UI or something like that,

1:32then we need to actually package up our application

1:34and get it deployed out to some environment

1:37so that those users can do their QA

1:39processes on the application.

1:42So the whole software supply chain is basically everything

1:45from getting your source code actually authored, and tested,

1:48and packaged up, and then deployed on dev, QA,

1:53and then finally production environments.

1:55That's the entirety of the software supply chain.

1:58Now during different periods within the software supply

2:01chain, we can hook into that process

2:04and perform certain validation steps.

2:07So one of those steps that we want to perform

2:09is to minimize the base image footprint.

2:12And what this basically involves is making sure

2:15that the base images that your application developers are

2:19basing their application components on

2:21are going to be as small as possible.

2:23There's multiple reasons that we want

2:25to ensure that we are minimizing our base image footprints.

2:30Because we want to ensure that we have as small of an attack

2:35surface as is necessary.

2:37So we don't want to be installing

2:38lots of software packages into our container images.

2:41Or for that matter, on the worker nodes in our cluster,

2:44we don't want to go through and install

2:46a bunch of software packages on those that we

2:48don't actually truly need.

2:50And so same thing for the base images that we're

2:52using for our container images.

2:54We want to make sure that those are lightweight container

2:56images because we don't want potentially vulnerable software

3:00components and dependencies to get installed

3:03into those images, and then increase the attack

3:06surface that an attacker could use

3:08to get unauthorized access to the applications running

3:13on our Kubernetes cluster.

3:15Another reason that minimizing the base image footprint

3:18is important is because when you're

3:20talking about scaling applications

3:22and creating multiple replicas for high availability

3:25for your different application components

3:27that are running on your cluster, then

3:29you want to make sure that those applications scale

3:31as quickly as possible.

3:33So imagine that you had a cluster that has maybe

3:3510 different worker nodes.

3:36And let's say that you've got a microservice

3:38that you deploy and you only have three

3:40replicas of that microservice.

3:42So basically it's going to create three separate pods

3:45on your cluster.

3:47Well, if you have 10 nodes in your cluster

3:49and you have three replicas of this service,

3:52then only three out of those 10 worker nodes

3:56are going to download the container

3:58image for that particular application,

4:00and then actually run a container from that image.

4:03Now let's say that you took that container or that pod, I guess,

4:09and replicated it additional times.

4:11So you've got three nodes that currently have that container

4:13image and you have seven nodes that

4:15don't have any awareness of that container image.

4:18So if you were to increase the number of replicas

4:21in your Kubernetes deployment controllers

4:23from let's say three up to eight.

4:27Well, now an additional-- potentially five

4:29additional worker nodes within your cluster

4:32are going to have to go out and download that container

4:34image from your container image registry.

4:37So that they can scale up and run additional pods

4:41and containers for your application to scale it up

4:44and basically horizontally scale it

4:46so that there's additional replicas of it running.

4:49Now if you have a very, very large container

4:52image, then the amount of time that it takes those five

4:54additional worker nodes to download the container

4:57images from the container image registry,

4:59extract it from its zipped format,

5:02and then actually create the new container from that image,

5:05it's going to take a lot longer.

5:07But if you slim down those images,

5:08you have small base images, and you're only

5:10installing the necessary components

5:12inside of those container images that

5:14are necessary for the application itself,

5:17then you're going to ensure that the application scales

5:20much more quickly than it otherwise would.

5:24Now when we also talk about supply chain here,

5:25we're talking about what registries are actually

5:29being allowed.

5:30In a production application that if you're

5:33working at a very large company and you really

5:35have to pay close attention to the security of your software

5:38supply chain, we want to make sure

5:40that our developers are not able to deploy

5:44container-based applications from just any registry.

5:47If I had to guess, I would bet that if I went out

5:49to Docker Hub or if I went out to Amazon Elastic Container

5:52Registry, ECR Public, those are both public registries

5:56that anybody can just upload their own container images to.

5:59Also Red Hat has a managed container image registry called

6:03Quay, Q-U-A-Y.I-O, I think.

6:06And anybody can just sign up for Quay.io

6:09and they can host publicly accessible container images

6:12on that service.

6:13And I would bet you that if I went out

6:15to any of those services, that I would

6:17be able to find container images out there

6:19that have malicious code.

6:21And so if we had a developer that was not

6:24paying close attention and they just

6:26went out to Docker Hub here, and they

6:29find some malicious container image to use as a base image

6:35here.

6:35So let's say maybe they do a search for MySQL.

6:39But rather than using the official MySQL container image

6:42to run their database, maybe they

6:44scroll down and go a couple of pages

6:46in, maybe go six pages in here, maybe

6:48they find some random person's MySQL container image.

6:52Well, that could very well be a malicious user.

6:55I don't know if they are or aren't, but it

6:57could be a malicious container image

6:59and have some kind of Trojan Horse, some kind

7:01of backend malicious component pre-installed

7:04into that container image.

7:05And so if that developer deploys this particular container

7:08image, then it could potentially have

7:10malicious software in there.

7:12If they don't do the appropriate validation of who the user is,

7:15and looking at the actual packages that are installed

7:19into the container image, and looking at the entry

7:21point of the container image to see what's actually being spun

7:24up with this MySQL image, then they

7:27could potentially introduce vulnerabilities

7:29into their Kubernetes cluster.

7:31And that's something we want to avoid.

7:33So by whitelisting certain registries,

7:35we can actually exclude these public registries

7:38like Docker Hub, or Quay.io, or Amazon Elastic Container

7:43Registry Public.

7:44And we can only allow container images

7:47that are hosted on a private instance of a container image

7:51registry to be deployed to our Kubernetes clusters.

7:56So let's say that, for example, you spin up this open source

7:59harbor registry.

8:01So let's say you deploy a private instance of harbor

8:03on your Kubernetes cluster and you set up a DNS name

8:06to route traffic to this harbor instance,

8:09you could actually create a policy

8:11and apply it to your cluster to only allow

8:14that particular registry to be used by your application

8:18development teams.

8:20Another important concept is digitally

8:23signing and validating digital signatures on container images.

8:27And so I've got a skill that actually

8:28talks about how you can use a utility called Cosign.

8:34So this is actually a utility from something

8:36known as Sigstore, which is part of the Linux Foundation.

8:39And Sigstore creates this utility

8:41called Cosign that allows you to digitally sign container

8:44images as part of your supply chain,

8:46and then publish those digitally signed container

8:49images to your container image registry.

8:52And then you can validate those container image signatures

8:56before you actually allow your Kubernetes

8:58cluster to deploy new containers onto your cluster.

9:02And by having that signing process in place,

9:04you can again, help to ensure that development teams aren't

9:08just randomly going out and deploying just any container

9:10image, that there has been certain approval processes that

9:14have been gone through in order to digitally sign those images

9:17and then validate them before you actually

9:19create those containers.

9:21And tools like what we talked about in the last video,

9:24like Kyverno and OPA Gatekeeper.

9:27Those types of policy management engines

9:29allow you to enforce things like verifying images.

9:33So we can say, verify an image using Cosign.

9:35Or we could basically validate the registry

9:39that it belongs to using--

9:42restricting the image registries that we

9:44are allowing based on things like DNS names, for example.

9:48And so by implementing these types of policy management

9:50tools, we can ensure that our supply chain

9:53security is secured.

9:56There's also something known as container image vulnerability

9:59scanners.

10:00And I've got a skill that talks about how to use Trivia.

10:02And use Trivia in GitHub actions,

10:05for example, to automatically do vulnerability scans.

10:09You can integrate Trivia with other components

10:12that your organization is using like Slack,

10:14so you get automated notifications

10:15if you want to from vulnerabilities that are

10:18detected in your supply chain.

10:20And so that's a really important concept,

10:22to know how to use these vulnerability scanners that

10:24can look at databases of known vulnerabilities.

10:28Basically what they do is they look at the packages that

10:30are installed, the dependencies that are installed

10:32in your container images, and then they'll

10:35query those against a database of known vulnerabilities.

10:38And then it'll give you a report that

10:40shows the severity level of these vulnerabilities

10:44and potentially how you can either remove that software

10:47package to avoid the vulnerability,

10:49or upgrade it to a newer package version

10:51so that that vulnerability no longer exists.

10:55Something else that's an important concept

10:57is static analysis of user workloads.

10:59What this is referring to is there's

11:01different utilities out there that will actually

11:03allow you to inspect your Kubernetes clusters

11:06and you can actually look at the workloads that

11:08are running on there.

11:09And so rather than doing a policy management perspective

11:12where you are using admission control to allow or reject

11:16certain API calls, you can actually

11:18just go out to the cluster and say, hey, show me--

11:20inventory all these different pods for me.

11:22And then I want to look for certain rules

11:24on those actual running pods.

11:26Rather than actually injecting yourself into the API pipeline

11:29and approving or rejecting requests.

11:32So it's basically similar to using those policy management

11:35tools.

11:35But rather than injecting yourself

11:37into the admission control pipeline on the Kubernetes API

11:40server, you're actually just doing

11:42an analysis of what's actually running on the cluster itself

11:46and then making determinations of what kind of action plan

11:50you want to take to rectify any potentially

11:53vulnerable configurations that you see on those running

11:56workloads.

11:56I hope this has been informative for you,

11:58and I'd like to thank you for viewing.

0:11Hi, guys.

0:11And welcome back.

0:12So, so far we've talked about cluster setup and hardening,

0:15we've talked about system hardening as well, microservice

0:19vulnerabilities and supply chain security.

0:21All of those are very, very important topics.

0:23But our final topic here is also a really important thing

0:27as well, which is around monitoring your Kubernetes

0:30clusters so that you have observability into just

0:34the behavior, the performance.

0:36The-- any odd behavior, anomalous behavior

0:39that could be occurring on those clusters, logging also.

0:43As we previously talked about, Kubernetes audit logging

0:45is a really important concept that you

0:47can see exactly what's happening in your Kubernetes API server,

0:51and then runtime security as well.

0:54Let's talk about some of the different topics

0:56that we might encounter in here.

0:57So "behavioral analytics of syscall

1:00processes and file activities at the host and container level

1:04to detect malicious activities."

1:06So I know that that's kind of a mouthful,

1:09but let's break that down and better understand

1:11what we're talking about in this learning objective.

1:14So what we've got here is syscall process and file

1:17activities.

1:18Well, the way that the Linux kernel works

1:21is that the Linux kernel itself exposes a variety of API calls

1:26that are known as system calls or syscall calls for short.

1:29And, basically, when you spin up a container

1:32or any other process, even if it's not containerized,

1:35on a Linux kernel, then that application

1:38is going to be making a variety of these syscall

1:41into the kernel.

1:42So that it can perform different functions,

1:44like creating network sockets, or opening

1:46a file for reading or writing, or things of that nature.

1:51That's why we're talking about process and file

1:52activities is maybe spawning off a thread,

1:55or creating a new process, or anything

1:59that's file system related or socket related on the system.

2:02And so as those activities are occurring

2:04on the hosts, the actual worker nodes on our Kubernetes

2:08cluster, we want to be able to observe what's happening inside

2:13of each of those nodes.

2:14And then we also want to be able to create some kind of rule set

2:17so that if something happens that looks potentially

2:20malicious, we want to be able to get notification

2:23of that potentially malicious behavior.

2:25And we may also want to log it to some kind

2:28of external system, like an Elasticsearch cluster

2:31or to a cloud-based logging service like Amazon CloudWatch

2:34Logs, for example.

2:35Or some other kind of logging system

2:37that you may implement like gray log, for example.

2:40And so there's actually a third party

2:41open source utility out there called Falco.

2:45And Falco is basically-- let's just

2:47do a search for Falco open source here.

2:51And so this is basically a third party open source utility

2:54that was originally created by a security company called sysdig.

2:57And this allows you to basically install this Falco agent

3:01on the worker nodes in your cluster.

3:03And you can create these rule sets

3:06to look for certain types of behaviors running

3:09on those worker nodes by inspecting things

3:11like syscalls through EBPF or E Berkeley Packet--

3:16Berkeley Packet Filter in the Linux kernel.

3:19Which is basically just a mechanism

3:20that exposes what's going on inside of the Linux kernel.

3:24So Falco is a very powerful utility.

3:26It also allows you to inspect, besides just Linux syscall,

3:30it also allows you to look at Kubernetes event logs,

3:32audit logs, to determine what's going on.

3:35You can create rules that specifically target

3:37those audit logs so that you can find

3:40potentially malicious behavior.

3:42So let's say that maybe, for example, just

3:44as a contrived example here.

3:46Let's say that you create a namespace on your Kubernetes

3:48cluster, or maybe a couple of different namespaces

3:51that have highly privileged applications running inside

3:54of them.

3:55So maybe one of them is a logging mechanism,

3:57and maybe one of them is a metric system, or something

4:00like that.

4:00And so you want to make sure that these systems that

4:03are doing logging for metrics and application

4:05and infrastructure logs are highly secured.

4:08And that if anything happens inside of those high security

4:11namespaces, you want to get notifications about it.

4:15Well, with the Kubernetes Event Audit Log Monitoring,

4:19if somebody has unnecessary levels of access to a cluster,

4:23like cluster admin level permissions,

4:25and they actually go and manipulate

4:27one of the running workloads inside of one

4:29of those privileged namespaces.

4:31Then you can actually capture that from the audit logs,

4:33and then receive some kind of notification,

4:36whether it's sending it to a syslog channel,

4:39or sending a notification to Slack,

4:41or sending you a text message.

4:43There's lots of different ways that you can actually

4:45develop integrations to send those notifications

4:48to some kind of endpoint on the right hand side here.

4:52Additionally, Falco also supports monitoring,

4:54it says cloud activity right here.

4:56So there is actually a plug-in that

4:57allows you to look at AWS CloudTrail logs.

5:00And so AWS CloudTrail is an audit logging mechanism

5:03for your AWS accounts.

5:05So if you are an Amazon Web Services customer,

5:08and you're using AWS to deploy various types of workloads,

5:12whether it's EKS, Elastic Kubernetes

5:14service, or whether it's just virtual machines running

5:17on Amazon EC2, or maybe you're just using Lambda.

5:20Or whatever it is that you're using,

5:22you can monitor your cloud trial logs,

5:25and Create Policy rules inside of the Falco rules engine

5:28so that you can determine what potential behavior is occurring

5:33in those CloudTrail logs that could be malicious.

5:36So Falco is a really interesting open source project

5:39that allows us that level of observability.

5:43Also a threat detection within physical infrastructure.

5:46So this is really just around intrusion detection,

5:49looking at audit logs, looking for anomalous behavior that

5:52could be occurring.

5:53Falco is one utility that could help you

5:55detect those types of things.

5:57If there's a particular user that's

5:59performing a particular action on one of your nodes,

6:02and you want to get notification about that,

6:05Falco can really help with that kind of thing.

6:07But also, more general purpose logging can help with that.

6:10So if you've got log files from your infrastructure that

6:13are being sent up to a third party service like Amazon

6:16CloudWatch Logs or Sumo logic, or any other kind of enterprise

6:20monitoring solution out there, that's

6:22going to help you detect what those potential intrusions

6:26into your infrastructure.

6:28Also we've got attacks.

6:30And so we want to-- again, this is referring back

6:32to intrusion detection systems.

6:34We want to be able to detect attacks that are occurring,

6:38and then lock down access to applications

6:41so that we can mitigate the attacker's

6:44access to our cluster.

6:45You could do that through things like network policy.

6:48We had previously talked about Cilium and Calico.

6:51Those are a couple of network policy engines

6:53that allow you to have pretty advanced control

6:55over the access that you have against your pods

6:59running on your cluster.

7:01Also, service mesh solutions like Open Service Mesh

7:04or Traefik Mesh or Istio and others

7:07can actually help with this as well

7:08because those allow you to do things like rate limiting.

7:11So if an attacker is trying to do something like a dictionary

7:14attack or just a brute force--

7:15brute force password attack against one

7:17of your applications, you can actually

7:19plug-in a service mesh solution that locks down access

7:22based on rate limiting.

7:24So that you can block those brute force and dictionary

7:28attacks against your applications.

7:30So all of this is really around things like Kubernetes audit

7:33logging, using things like Falco to do monitoring, using

7:37enterprise monitoring solutions to gather

7:39logs from your clusters, to get metrics from your clusters,

7:42and things like that.

7:43One other thing around immutability

7:45of containers at runtime.

7:46If you're not familiar with the term immutable,

7:48it basically just means unchanging.

7:50So if you have an immutable container,

7:52it basically means that that container once it's spun up,

7:55can't actually change.

7:56And so one of the things that in Kubernetes, a security feature

7:59of Kubernetes is--

8:00allows you to create containers with "read only root file

8:04systems."

8:05That's a feature within the security context of your pod

8:08configuration.

8:09I would encourage you to just go out

8:11and Google "read only containers on Kubernetes."

8:15And this will show you basically how to create--

8:18here's somebody's blog post that shows how to create

8:20"read only file systems in Docker and Kubernetes."

8:23But I do know that they have some documentation out here

8:25under "configure a security context for a pod."

8:29And there is a property called "read only root file system"

8:33that allows you to set the container's file

8:35system as read only.

8:36So basically when you spin up a container from a container

8:38image, normally you have the ability

8:40to just write data into the container's file system.

8:43But if you set the read only root file system property

8:46to true in your containers, then you

8:48can actually prevent any data from being written

8:51to the container's file system.

8:53And that's just one less way for attackers

8:56to inject malicious code into your applications

8:59if they find a way to run unauthorized code

9:02inside of your application.

9:04In any case, that's kind of a good summary

9:06of all of the different learning objectives

9:10that we have in order to pass the Certified Kubernetes

9:13Security Exam here.

9:15So I hope this has been informative for you,

9:17and I'd like to thank you for viewing.

9:18And good luck on your CKS exam.