Demo: Chainguard’s Enforce for Cloud Native Application Security

Key Takeaways

[Music] and actions there used to be this advertisement that was like popular in the northwest for Rainier Beer they go Rainier Beer Jesus ever ring a bell no okay but I want some now so advertising works okay because I was thinking [Laughter] [Applause] nice that's just I'm offended that's what I thought of so we're going to look at a demo from chain guard and you're Eddie zanesque I am hello hello Eddie and you're a software engineer I am so what are we going to look at so today I'm going to show you chain Garden Force which is our continuously verifying policy enforcement engine for all things containers and supply chain security okay great let's take a look yeah so what are we looking at right now so we're looking at the enforced dashboard and we can see that I have a single cluster that's already set up uh installed into enforce so who's this for who would be looking at this yeah so this is for anyone who is concerned about security of their containers right so security Engineers application evidence uh platform Engineers okay so kind of people in different roles but they want to be able to get it kind of get a glimpse what exactly are we looking at like so if I'm an engineer I'm looking at this what am I looking at I'm looking at the policy compliance I'm looking at what else am I looking at here yeah so this is our overview dashboard okay so this is like quickly at a glance I can see I have a single staging cluster installed I can see kind of a breakdown of the different packages that are running okay and I can see that some of my images 11 out of 32 are compliant and I have a bit a bit failing right now ah okay and these are policies that you can either pull from a catalog or you can craft yourself okay to enforce all sorts of different things okay so we have two failed policies we have a policy compliance of 34 yeah what does that tell them that tells them that they got a bit of work ahead of them yeah I would think so right so I can show you we can take a look at this single cluster here and here I can see those policies and what they're matching and what's failing so these are all the containers that are actually running inside my cluster uh and the really cool thing my favorite part about enforce is we can see the breakdown of all the packages of all these different workloads why is that your favorite because the hardest part about dealing with something for like log for Shell was figuring out what workloads you had were vulnerable okay and we give you that view with a searchable interface that you can go from taking weeks to figure out however long it takes you to type in a word was that pretty important that development for y'all to have this aspect to it yeah that must have been we built the tool that we wanted to use as Engineers ourselves um because what were the what were the tools like beforehand what were you trying what are you trying to do yeah the tools it was all by hand yeah when Cisco was talking to Congress about dealing with log for Shell in the first place they they talked about how it took them x amount of time I think it was like two weeks to come up with a plan to figure out what they had that was vulnerable oh wow that's a long time that's just to figure out a plan to figure out what we're vulnerable right because they they're shipping so many different products so many different routers so many different firmwares yeah um and so that's kind of my favorite part about this is we hopefully cut that down from two weeks to a few seconds here okay that's interesting so I can show you here so the packages I can see that I have some Maven packages running you can see that log4j is actually registered there I can see some Alpine packages so this is like the um openssl version for Alpine so I can see the version and then I can actually drill down and find out what workloads that's running with so one of the the things they had at Google is a term called build Horizon and it was uh kind of like an encapsulation of a bunch of different security for your your production workloads but the one that we're focused on here was uh the artifact age so how long this artifact has been since it's been built and so you can actually have an enforcement policy here that says anything that's older than 30 days I want to flag and fail because maybe you should do a full rebuild to get some OS updates or something and so that's just this policy here I can see that quite a few of the images are failing because they just haven't been rebuilt in 30 days um the other thing I want to show you is we've heard from a lot of our our customers that you know they have a team that might be spinning up a new cluster that's not already enrolled in in force and um kind of like they they want to keep tabs on new clusters as they're created and so we actually have a new feature that we're rolling out called Discovery and so I can do a chain CTL clusters Discovery and give it a provider flag of gke and Cloud run so it's not just kubernetes it's actually workloads that are running in AWS cloud and ECS and eks gcp a bunch of other places and so this is going to slurp in my Google Cloud credentials and so that's what we're looking at the credentials yeah well I have a trust relationship set up so I can see that it found two other clusters that are eligible in my gcp account so this is my production cluster and then this is actually my cloud run environment okay and so I can tell it to go in and enroll those and we'll see back on the dashboard here that we're going to have two new clusters show up so you can continuously run this as your engineers and your your platform teams are creating new clusters and maybe they're testing things out they just have to be enrolled exactly and they don't have to enroll themselves which is the magic part okay moving the burden from them having to sign up and add an agent or something to their cluster I imagine that's something that is helpful to have automated because otherwise you're just waiting kind of for that yeah to happen I would certainly be running it on a continuous job yeah and you can see that there it's going to ingest all those new clusters and all those new images it's going to recalculate some of the failing stuff we can see that the new production cluster has some other packages running so I have a bunch of go applications there should also be some node.js ones in here so we can detect any type of workload and pull up their s-bomb and show you across all of your different languages that your teams are using so you're not just restricted to one language uh here's the npm packages right so I can see all my NVM packages and their versions another cool view is looking at the workloads so I can break this down and see that I have tecton running and tecton has a couple different packages that are running as well and then another policy that I have is tecton must be signed right so we integrate heavily with Sig store and we can enforce that we want certain identities to be signing the images that are running in your cluster so it's actually I can tell that some of these images from tecton aren't actually signed and we can flag on that so now we're looking at it and I said the violations are 14 and the cluster is one the violations would be how are you defining violations so violations are going to be the uh the images that are failing this particular policy and this policy says Hey I want these uh this is actually a public key that we're checking for but it could be any sort of signing Authority or identity okay and then the last thing I wanted to show you was we have a concept of enforcement okay so let's say that we have this policy created for to prevent log for Shell right so we don't want log for Shell introduced to our environment again we and so long trying to clean it up and make sure everything was up to date that we don't want developers to deploy a vulnerable version and so that's what this policy shows here it's got the vulnerable versions listed here it's kind of a big list but what this is going to do is it's going to check inside of that metadata that ships with all those containers that are built and it's going to find which ones are vulnerable and so I've actually gone and I've enabled enforcement on a particular namespace we've designed and forced to be gradually rolled out so you don't have to start by blocking everything you can start with a like an observed phase where you could see what's going on and slowly opt into enforcement on different workloads so let's say that I'm a application developer and I'm going to deploy a vulnerable version of log4j that I don't know is maybe in this image so I've got a demo image here that has that vulnerable version in this cluster this namespace is opted in for enforcement and if we see that I run this it's going to evaluate that image pull that metadata see that it was actually built with a vulnerable version it's going to deny it so right there I can prevent any sort of vulnerability that I know about that I have a policy for for being reintroduced back into the cluster uh and so we have this policy catalog I'm not sure if I mentioned it but we have some of those pre-created policies and that log for J image uh the lock for Shell policy is one but we've tried to make this really easy for users to get up to speed and start with sort of like a springboard to draft their own policies so that's that's the chain Guardian Force in a nutshell well thanks so much Eddie I appreciate the demo yeah thanks for coming by thanks for having me if you like this video please give us a thumbs up and if you'd like to see more videos like this you can always subscribe to our YouTube channel we're on all the major social media platforms you can always find us at the newstack.io we hope to see you soon foreign [Music]