 Thank you once again everybody for joining. My name is Andy Byte. I'm in a marketing with Aqua Security and joining me today is Liz Rice, our vice president of open source software. Hi Liz. Hi Andy, thanks for having me. So this is part of the CubeSec Enterprise online webinar series. This is week number four of what is now scheduled to be 11 weeks. So for those of you who signed in early will be sending out three more additional weeks for you to register for, but this came about when it was not clear what was going to happen with CubeCon Amsterdam and now we all know it will be a virtual event in August and we look forward to seeing everybody there. But in the past three CubeCons, we have run an event called CubeSec Enterprise Summit where customers have come to talk about the challenge of deploying Kubernetes in enterprise production environments and we had a bunch of speakers signed up to do Amsterdam planning to go and of course thanks to this global pandemic we had to make some changes but we took many of those speakers who were willing to do this as a webinar series and slotted them week by week. This week is Liz's turn to talk about her new book. So Liz in addition to running open source software for Aqua you're also an established author with a brand new book. Yep I am we will come to that shortly. Okay so without further ado let's go over some of the housekeeping issues and then we'll let Liz kick this off. So if you do have questions today because we have a lot of people on great turnout today we will be doing questions via your go to webinar panel so if you put a question in there we will try and take some throughout if they seem like they're really relevant to the current conversation otherwise we'll try and take some at the end and if we don't get to your question we will reply via email. We will make us copy the slides available after the event and we are interested in your feedback as well so on what was good about today other things we will be doing some polls today as well so we ask you for those who are here live not viewing this as a an archive you're here today you're live. We will be polling and we'd love to see your answers and for those of you who are watching this on demand now you'll see everybody's answer think about your own responses we go through. So with that let me turn it over to Liz and to talk about the her new book and some of the key findings in that and share that with you today so go ahead Liz. Wonderful thanks Andy and hi everyone thank you very much for coming and joining us today and I would really like this to be as interactive as we can make it so as Andy says there are going to be lots of polls during this talk to to help you get involved and yeah please do ask questions and we can try to take them either as we go along or we'll answer them at the end as Andy says. So I look after the open source engineering team here at Aqua Security and as Andy mentioned I also an author I recently published this book called Container Security published by a Riley if you're watching this live you should find an electronic copy of the book in the handout and if you're not watching live you can download an electronic copy from Aqua's website for just in exchange for your contact details and Mary did ask me to make one point Liz the handout if you do click on the handout in your handouts tab it will open in a separate browser window you might not notice it some people have opened multiples and they find them all later so look for that separate window to pop up if you do download the handout. Okay great and of course if you want a physical copy it's available in your favorite bookstore so go and order it from your local bookstore. So in the book right at the end I have an appendix that's like it's called the security checklist and it covers a list of 28 questions that you should ask yourself to help you establish whether there are things you could do to improve the security of your deployment. Now in today's webinar we don't have time to cover all of those questions and all of those checklist items but I thought I would highlight a few of my favorite and perhaps the most important questions and we'll concentrate on those and explain them today. So we're going to consider six questions and they spread across the whole container life cycle from the point where you're building container images right through to where they're running live in your deployment and by thinking about these questions you might leave this talk today with some actions that you can take to make your own deployments more secure. So for each of these six checklist items I'm going to ask a question we're going to open a poll to get you thinking about that question and why not let's get started. So let's bring up the first of those questions which is about the build machines. Are you running your builds separately from your production cluster? Are you running builds on different machines or virtual machines? It looks like people are overwhelmingly on the right side of this one Liz. That's good that is good to say yes we're seeing the numbers are changing as your boats are coming in but it's looking very much as though your your builds are running separately from production which is very good news as we will explain shortly. Looks like pretty much everyone has voted so nearly everyone has. I think we have a pretty significant view there that the vast majority of you are well congratulations you're running your builds separately. Of course why is that important Liz? Well let's let's just consider exactly why that is important. So if your build processes are on the same machine as your application workloads they're sharing a kernel and if anything were able to escape the build process onto the host it would have access to those applications and remember that Docker files that we're typically using to yes if your Docker files contain instructions to run basically arbitrary code you can have any instruction here that's going to run during the build. So if someone manages to compromise your Docker file and compromise those build instructions they can get the build to do pretty much anything they want it to. Now this is even more serious if you are using a docker build process that uses the docker socket because the docker socket is essentially root access to the host. So my main advice here for the you know small percentage of you around 10 percent that either don't know or maybe running your builds in your production cluster the safest thing to do is keep your builds entirely separate. Now it is possible to run builds in your production environment in a safe way so I have caveated this that if you know what you're doing you can run your builds in production you could use for example a sandboxing like G visor you could potentially be scheduling your build jobs to specific nodes in the cluster where applications don't run. You could also be using rootless build processes things like your mochi or builder or the docker build kit in rootless mode all these things that basically don't require a docker daemon. So there are ways you could safely do this but it's probably safest unless you've thought very carefully about it to just keep your builds separate from your production cluster and the good news is it seems like most of you are doing that so we're off to a flying start that's good. So the next question is going to consider the images that get built so let's get ready for the next poll in your container image builds is all executable code added to the container image at build time. So if you have containers that update themselves when they start running or that load extra executables you need to answer no to this question. Okay lots of answers coming in this isn't quite as clear cut but it looks like we have a pretty large majority who are keeping there all the executables added at build time. Okay I think we've got the majority of answers now so let's take a look at those results. Okay so around two thirds of you are keeping your or adding all your executable code to the container images during the build. A significant number of you are not sure so let's explain a little bit more about what we mean here. So once you build your application container image it's a really good idea to scan it for known vulnerabilities that might exist in the packages or language dependencies inside that container image. If you're not already scanning your images do please start doing that there's lots of free and open source tools available for vulnerability scanning including our own trivy it's entirely free so just go ahead and use that. Scanning your images lets you know if your containers have known vulnerabilities that attackers could exploit so you want to scan basically to have some confidence that you're not running something like shell shock or heart bleed or any one of thousands of other known issues. So then you can run your container instantiated from that container image in the cloud and you want to know that all the executables in that running container were scanned and that they have been deemed safe to run. If you do something that adds additional code to your image maybe using package managers like apt or yum to add or update packages or maybe you're using curl or ftp or git clone or anything else to grab additional code that then can be run inside that container well any of that additional code hasn't been scanned and you really don't have any way of knowing that it's safe to run. So best practice is to only run code in your containers that was present when you built the image we call this treating our containers as immutable and a change to a running container is sometimes called drift and we're going to come back to the idea of container drift later on. Obviously it gives you some flexibility to modify a running container I guess that's one of the things people are looking for is there ever a good reason to do this or really you would say if you need to make a change go back to that app build it fresh and never do this. Yeah I'm sure you know people will have some kind of edge case where it is critical but for you know 99.9% of normal applications there's no reason to do this it's much better idea to rebuild your container image and redeploy with the updated code. Great yeah thanks. It seems like most of our attendees are already doing that but those of you who maybe aren't or you know maybe need to go check this is it's all really about scanning and having confidence in the code that you're running. Okay so when we run our containers we're running the container is defined by a container image and then it's configured with flags maybe docker parameters or the pod spec yaml in kubernetes. Are you avoiding using the privileged flag that's our next poll if we can open that up? Okay so I've tried to phrase all these questions so that if you're doing the right thing you're answering yes. No avoiding. Don't tell people that now they're going to answer yes to every poll even if they aren't doing the right thing so they don't want to admit it. Okay this is coming in thick and fast it looks pretty similar numbers to the last last one so I think we've got enough we could probably close now. It's interesting because a fair number of people don't know here right you know so again it may be that people who are in development aren't sure how the operations people are deploying it or what do you think's going on there? Yeah well I think it would behoove everyone to make sure that we're not running our containers with privileged because it has been called the most dangerous flag in computing. I quite like that quote from Andrew Martin from from control play. I think actually that's a you know a debatable point I'm very open to suggestions for more dangerous flags that could be quite a fun question so I'd love to hear your thoughts on that but let's talk about why privileged certainly is a candidate for the most dangerous flag in computing. So it was introduced for a reason it allows Docker to run inside Docker and that was really introduced to help developers at Docker work on Docker itself. Now it's been used for other reasons like running builds you might have exceptional reasons why you need to use it but for the vast majority of applications it's not really necessary. Let's talk about the things that it does what's happening when you do run a container with dash dash privileged. In order to talk about this we need to understand a little bit about Linux capabilities so back in the midst of time you were either root with all privileges all privileges or you were an unprivileged user with no special privileges and then capabilities were added to the Linux kernel to make these permissions more granular so that you can grant or deny specific privileges. When you run a container by default it gets a sensible set of these capabilities which don't include for example any of these three that I've listed here that really most containers don't need to do. Most containers don't have any reason to be modifying the kernel modules they don't need to be changing the system time. You want to think very carefully about granting the P trace capability that lets one process trace or modify any other process pretty powerful capability that so you want to restrict privileges and only grant them where they're absolutely needed. So when we run a container we can specify the set of capabilities that are granted to that container and to start with here in this first example I'm running a regular Ubuntu container and I'm granting all the capabilities and you can see that if we look at the status file for the process one inside that container we get a value with lots and lots of Fs it's a set of big flags and all of the flags are turned on. Then if we run the same container dropping all the capabilities we look at the set of capabilities and all the flags are turned off the values are all zero and then if we don't specify any capabilities at all we get that default set that I mentioned and it's kind of a mixture so some of the flags are off a lot of the flags are off some of them are on. Now if we run with dash-privileged it grants us all of those capabilities so for the capabilities it's the equivalent of adding cap add all so we've granted this container all of the possible permissions and privileges that it could have but that isn't the end of the story. I've run the same container without and with dash-privileged and you can see that with the privileged flag you get access to a lot more devices in fact with the privileged flag you get access to every single device on the host and you could use that to for example erase politicians on the hard drives on the host so you really really really don't want to have a container escape that has dash-privileged because inside that container you can do super dangerous things so think very very carefully before granting dash-privileged. Now Liz you highlighted three potentially risky capabilities what's the worry about being able to change system time what where do you get into trouble if you allowed that? Yeah so well at one level you might say why should one container be able to change the time for other containers you can mess with programs pretty seriously by changing time. If you expect things to for example if you expect to see the latest value that something was set to a value you might look for the most recent update and if you change time in the meantime well how do you know what's most recent? So it has serious risk to applications it's it's a serious risk yeah okay great and time is interestingly something that recently has started to be namespaced so that in the future I would imagine in much the same way that today you can grant a container the sysboot capability and it can't actually boot the whole machine anymore it used to reboot the whole machine now it will just kill the container and I would imagine that in the future time being namespaced would mean that we could grant containers the system time capability and it wouldn't necessarily affect the rest of the system but today it's it's not something you want to really give away lightly. There is one other reason why dash-privileged is maybe sort of psychologically dangerous and that's it's it's all about the name so there's an implication that if you have a container that doesn't have dash-privileged maybe that means it must be unprivileged and that's really not true by default your containers do run as root you do not need the privilege fag to be running as roots you can find out all about that in chapter nine in the book to find out more about that the point is don't give away dash-privileged just to get root because you already have it all right. I see a question that came in sorry. Someone in the chat said some security solutions can be affected if system time is changed as well so you know if you if you knew that some some sort of antivirus or other malware detection engine was running and you could change the time it might impact that so that's a good point. Absolutely all kinds of diagnostics and tracing and observability can be messed up by messing with time. There's also a question about what about running with privileged on the hosts where the docker service itself is running with a restricted host user and not root okay so I guess this is the idea that you're so there is a new newish idea of rootless containers the ability to run containers as unprivileged users the best sort of use case example for this is in an environment like a university where you might have a shared set of machines the users are unprivileged and until rootless containers if you wanted to let students run the container well you couldn't do that because it's it's essentially a privileged operation rootless containers allow you to run containers as an unprivileged user and I'm guessing that's what this question is talking about around if you run as an unprivileged user if you can run a container as an unprivileged user and I'm not sure whether that privileged would error in that situation or whether it would carry on and try to grant you as many privileges as possible you certainly wouldn't be able to get things like all device access and I'm not sure what would happen in terms of capabilities that you didn't already have I suspect you the kernel would prevent you from getting extra privileges but I'm not sure whether it would actually error people should definitely look into that then before just assuming it's all safe yes I think it would be a bit of a weird thing to do though to have a rootless container and then run as privileged I'm pretty sure it will be not it won't allow you to escalate privilege or certainly if it allowed you to escalate privileges that would be a bug in my opinion all right so the next question that we have is really thinking about the hosts on which your containers are running are you keeping your hosts up to date with the latest security releases so let's open the next poll this is about things like the Kubernetes software that you're running on the hosts any logging system observability all kinds of software that you might be running on the host machines okay answers are coming in looks like the majority of you are doing pretty well on this but it is a big challenge to keep all of those software components up to date right I mean it's uh maybe you can keep the big pieces done but do you even know about all the other smaller components you might be using right well well there's a good argument for keeping your hosts running as small a set of software as you possibly can make sure you're only running essential services so just under three quarters of you are keeping up to date with the latest security releases good number of you aren't sure or know that you're not now and the reason why this question kind of came to mind particularly for this presentation was only a couple of months ago I got asked why our cube bench tool doesn't support Kubernetes 1.8 now even at the time when I was asked this question in April the latest release of Kubernetes was 1.18 then Kubernetes supports the three most recent minor versions so 1.16 17 and 18 1.8 was you know two plus years old I think maybe three years old so I recorded a video I'm not going to show that now you can you can find that on our open source YouTube channel and but I basically said you know you really want to be running with supported software 1.8 of Kubernetes is sufficiently out of date that it's not getting security patches and we know there have been some significant security issues in Kubernetes since 1.8 so really the you know running cube bench cube bench is going to tell you if you haven't configured your Kubernetes according to best practices and it doesn't really matter whether you've configured it according to best practices if you know it's full of well full is an exaggeration but if you know there are exploitable security issues in those really old versions so I explained that in this video I then got quite a fun response from someone who you know was pointing out 1.8 shock horror face and clearly he thought that I probably should have been a little bit more harsh, shouty about running such an old version I will point out this was not just a random person on the internet this this was actually a you know an aqua customer so you know there are corporate customers enterprise users out there who take their security seriously but for whatever reason hadn't been taking it security seriously enough to upgrade the Kubernetes systems this stuff is all important all right I see a couple more questions coming in yeah one of them was what what can be done about critical vulnerabilities in your Linux kernel that might remain even after installing all the patches well if there isn't a patch available I mean there really isn't anything you know you can only patch something that has a fix available and depending on the vulnerability there might be some other mitigating things that you could do you I don't know for example with turning off certain software services that maybe you would normally run but if you decide they're not critical and they're interacting with the vulnerability there may be things that you can at least use observability tools to detect whether a problem has actually happened but yeah fundamentally if a patch doesn't exist you kind of have to wait for the fix to be released pretty rare these days that you're going to find a critical vulnerability that doesn't have a patch well there may be times two where people aren't able to to patch if it's you know at the kernel level it's probably more critical to do it but even in application software you know we have the the aqua virtual patching capability as well which would be one you know our v shield solution which would at least pick up or detect and even potentially block some of those accesses but for if you're interested in that take a look at one of our other big webinars we won't go into that today all right and there was another question there saying you know this is limited to the support of my kubernetes distro vendor that is absolutely true one of the benefits of using a managed distro is you know they're collecting together all of the upgrades for you they're maybe collecting together you know not just the kubernetes but maybe the maybe the distro also includes observability solutions or logging or a service mesh or whatever else and so hopefully they are hopefully your vendor is applying upgrades and supplying those upgrades to you in a timely fashion particularly for you know they don't happen that often but we do occasionally see serious vulnerabilities in kubernetes or other cloud native software if they're not giving you timely patches i would definitely call up your account manager and shout at them okay so now we're talking about our applications actually running live in our production cluster and some of your application containers may need secret information like passwords or tokens so that they can do their job maybe your application needs a database password for example the poll question do you know are your secrets encrypted at rest and in transit we need them to be safely encrypted wherever they are okay answers are coming in pretty fast this one is just over half of you at the moment saying yes good looks like a quarter of you in the no and i don't know camps a little bit more of a balanced response this one is probably harder for people to to follow and adhere to consistently hmm yeah okay should we close that poll a couple more people select couple more percentage points said yes right at the last minute there um yeah so nearly half of you saying no or i'm not sure whether or not my secrets are encrypted at rest and in transit now i'm going to guess that most of you are using kubernetes and a good number of you will probably be using kubernetes native secrets and if i get a secret using kubernetes control i can just decrypt well it's not decrypted at all i can get the plain text version by base 64 decoding i don't need any secret to do that it's not encrypting it's just an encoding there's nothing very secure about that at least that doesn't look it but you might be saying yeah but in order to run that kubernetes control command you have to have access to kubernetes you need a kubernetes config file giving you the the permission to access the kubernetes api there could also be our back role based access control in place to limit the set of secrets that i can actually get at you know hopefully we're controlling access so that people can only get to the resources that they they need to and applications can only get to the resources they need to so there could be other controls preventing unauthorized people or applications from accessing that c pro over the kubernetes api and that's true and that's good but this is not the end of the story if you're storing secrets natively in kubernetes without any additional plugins they're going to be stored along with all your other state information in the xcd database by default now if i go and search for my secret value inside the database i can see that the database file matches my secret value and i can actually look it's a binary file so it's not super pretty but i can go and just look at that xcd database file and we can see my secret is just sitting there in the clear so anyone who has access to the database file on the host machine might be able to get at any of the secrets that are stored in there it's pretty trivial once you have access to that file because xcd by default is not encrypted now you do have options one of your options is to encrypt xcd you can configure it to be encrypted another alternative is to use a secrets manager to hold the secret values separately outside of xcd and you might very well consider that most of your kubernetes state information isn't terribly secret and that it doesn't need to be encrypted but your secrets are another matter so you might want to take advantage of something like hashicort vaults or the key management systems from your cloud provider somewhere secure that you can store those secrets and there's lots of kubernetes integrations for secret storage all right we are coming up to the last question the last poll for today and you remember we talked earlier about treating your containers as immutable so the question here is can you prevent containers from drifting do you have a way of spotting when a container attempts to run something that wasn't in the original container image and generally I guess the the belief here is that um that should never happen is that the containers once you've you've built them we don't uh we don't want anybody running anything that was not specifically allowed in that first version right correct and if you do see something running inside a container that's uh that wasn't in the original image provided you're treating your containers as immutable it's almost certainly a sign of compromise never and our research team have seen you know containers being compromised to run cryptocurrency miners that's the kind of classic example at the moment and it looks like this is a hard one for people to solve because a lot of people haven't and and this is a harder problem uh essentially you know there is not much there are some open source solutions for detecting there are not any open source solutions that I am aware of for preventing container drift but let me show you something that is pretty cool in aqua um so I have a demo here I'm going to run uh an Ubuntu container and uh we're going to look in the aqua console and I can see my Ubuntu image has a default aqua profile associated with it and I've set up that profile to what to have drift prevention turned on right now it's in audit only mode but this is detecting if we try to run an executable that wasn't present in the original image now I'm going to create uh an executable I'm just going to create a short script it's not going to do anything super fancy and in this instance it's going to be completely harmless but it should show the principle all I'm going to do is write a message to the screen with this script so I've created that file I need to make it give it the executable bit so that it can be run and then I can just run that script and it writes that message to the screen now that is a new executable added to the container that was not present when we scan the image so this is drifting action and we can see that in the audit logs it has been detected aqua has been able to spot that you can see the security control is drift prevention now if we want to take this a step further and prevent that drift from happening we can turn on enforcement and now if we try to run that same executable we get permission denied error we didn't even need to restart the container which is pretty pretty nice and then we can see in the audit log that this time we've got a block audit log here for the same reason for for drift prevention so I'm literally pressing two buttons one to detect the drift and and then you know changing it to enforce and and now this isn't happening right yeah and this drift prevention enforcement is it's probably one of the most advanced controls that you can that you can run for containerized security and it's so powerful because of this concept of container drift of immutable containers if you treat your containers as immutable this is like a superpower preventing any of those unexpected attacks if an attacker can compromise your container but then they can't actually do anything unexpected inside that container that's super powerful right so in conjunction sorry no I was gonna say in conjunction with one of your earlier uh checklist items of you know treating your own containers as if they're immutable and not adding things at runtime and now not allowing anyone who potentially was able to make a change to a running container which is not easy but is doable you would detect that here using using this kind of capability absolutely so this is kind of you know the gold standard for container security at runtime really all right great hey if we might both you have any other questions go ahead and enter them now we'll open it up as as Liz wraps up here we'll take some more questions at the end yeah so we just talked about six questions I think they are six pretty sort of interesting and important questions around the security of your deployment some of you may have answered no to some of these questions and that might be fine you might have very good reasons to answer no but if you're not sure of you you know a lot of the time the sort of default best practice is a good idea so if you're not sure maybe go and find out because there could be some things that you could do relatively straightforwardly to improve the security of your deployment so hopefully you've already found the the download of the book if you're watching the recording of this presentation later you can go to info.aquasect.com and you'll find the link there with a picture of the book so you should be able to find that pretty easily physical copies also available from your favorite bookstore with that let's have a look at the questions that have come in let's mute it there there's one there's one about cube bench can you run cube bench on a high availability kubernetes cluster so with one more than one master node yes you can so and maybe take a minute to explain what cube bench is for some of the people on here might not be as familiar with that yeah yeah so we mentioned it briefly earlier on it's a tool for checking the configuration of kubernetes and whether or not it meets best practices those best practices being defined by the center for internet security so it's another kind of checklist of configuration settings for all the different components of your of your cluster so I don't think in the current version of the cis spec I don't think there's anything specific to having more than one master node but I would expect that the other tests would all apply now cube bench configuration we could probably spend a whole other webinar talking about all the different things you can do with cube bench for configuration because you can you could modify the tests if you felt that was appropriate for your situation cube bench will try to auto detect the kind of node that it's running on so a master or a worker node in the most recent version there are different sections of tests for things like whether or not it's running at cd again it will attempt to auto detect that the auto detection does rely on being able to execute things like cube control or cube bench which have to be mounted into the path from the host so there is some configuration there we have some example jobs job yaml that can help but that probably don't cover every single possible scenario I would very much expect that it's possible to run cube bench in a high validity cluster and if you find specific problems there then please do raise them on github and we'll try and help you out all right I mean is this a good opportunity actually to talk about your latest news out of your open source team in terms of the starboard project and as a way to monitor cube bench so I'm just looking at the there's a lot of questions as well wow okay um I will come back to that in a second yes so starboard um is our latest project from my team the open source team at aqua and the idea of starboard is to take the output from different security reports cube bench being an example I mentioned trivy vulnerability scanning aqua vulnerability scanning and I think also reports from third party security tools we have an integration with Polaris um from fairwinds which uh audits your pod spec yaml anyway we take all this security information and store it in the form of kubernetes custom resource definitions and then that way it's accessible over the kubernetes api and with uh an octon plug-in you can see the security information right next to the kubernetes resources that applies to so that's uh much more convenient for retrieving for people who are used to tools like cube control or who are used to things like the opt-in dashboard all right um so I see a question there about how about securing fargate containers or azure container instances yes so the interesting thing about fargate and container instances is that you don't have access to the host so some of the things that we've talked about today things like uh updating the software on your host well you don't have control over that that's something you have to rely on the client provider to do um if you some of the other security controls still apply so things like vulnerability scanning still applies and things like the drift prevention that we just looked at that is supported by that aqua product so you can run that kind of security in these environments like fargate and aci okay there's another question here you know looking at drift prevention and um obviously the the control that's in place for that but someone was saying wouldn't the change in the size of the container image be detected as well why you know why do I need to do drift prevention in real time and I guess that you know that you know is that something that you would be able to block in real time what based on the size yes so one of the interesting things about uh container immutability is that there are perfectly legitimate reasons why additional files might get written into a container you might have a process that writes some temporary state to a file that it's just going to have running locally inside the there's just going to store inside its own file system um so that would affect the size of the running container instance um but it wouldn't necessarily be executable and it's really only execution that you care about um you care about uh an attacker getting into a container um actually executing something inside that container they have to be able to execute something in order to extract information and if you can prevent them from running those executables then uh you kind of won the battle so actual files uh file size is not really not necessarily a strong indicator of compromise okay all right great um there's a ton of questions here I know yeah we'll get back to all of them if you want to grab one or two more I would like to answer as many as we can get through uh okay let's spend a couple more live and then we'll wrap up and uh let's see here yeah there's a question here it basically just says binary authorization and so this is also known as um well it's part of something that we can call image assurance so uh we also can think of it as admission control so the idea that before you run a container you can make some kind of policy checks on the container image and its configuration and decide whether or not it's safe to run so yeah there's lots of different approaches for doing that there's things like opa and gatekeeper in the open source world binary authorization is I think it's google's own term it's certainly that they talk about bin orce in in gke um yeah and tools like aqua have very flexible um policy configuration so that you can do things like only run a only allow containers to run you know if they meet a certain set of criteria and um uh you can either prevent or alert on uh failure to meet those policies so is that related to there's a question here about uh using image signatures for container integrity is that something you cover in the book is that a new development um as in how does that relate to what you're talking about yeah so um it relates to what we talked about around um immutability um in order to detect whether or not execute in fact you know the the demo that we just showed there that the um a new executable had been added the aqua solution is sophisticated enough to fingerprint the different executables so that you can't just if I had renamed that script to I don't know LS or something or if I'd overwritten uh permitted executable it would have detected that it wasn't the same uh original difference yeah yeah all right is there one more question you want to take right now and then uh as I said if for those of you if we didn't get to your question we will uh uh make sure we answer via email yeah we're going to have to be writing a lot of uh a lot of questions okay one question here does keep bench have support for scenario where xcd is in a separate node than the master node yes the most recent version of the uh cis kubernetes benchmark has a separate section for xcd and we do run that as a separate section so yes we can we can we have that support all right great so I'll take this opportunity to thank you Liz for sharing the insights into your book well thank you for writing the book and everybody can get a copy of that um uh as we said either from the handouts before you leave today on the handouts panel or um online from from aqua sec.com you can you can download it from there and but we appreciate you taking the time to take people through some this is just some of the checklist items uh that that are covered in the book and there's obviously a lot more depth on each of these in uh in the various chapters so uh thank you again for sharing with it sharing sharing that with us today there are a couple of other things for those of you on the webinar who are looking for a next level even beyond container security and just continuing your um evolution here if we could go to the next slide we'll share a couple of other resources that uh you could be looking at here