 All right, well welcome everybody to another image builder SIG part of the OpenShift Commons community and this week We have Michael Withrow with us who is going to talk about how to make your containers more secure With some of the technology from Twistlock. We're going to talk about it in the context of OpenShift The way that we do these SIG meetings is a little different We're going to let Michael talk for you know, 20 or 30 minutes and give a demo And then we're going to open it up for a conversation with everybody who's online You can ask questions in the chat And talk amongst yourself in the chat while he's talking but once he's done talking he's taken a breath We're going to turn it on and just let everybody talk With Michael and ask any questions that they might have so without any further ado Welcome to the image builder SIG Michael and why don't you take it away? All right, thank you Diana. I really appreciate it and thanks everybody for attending. I understand time is money So I really appreciate it. All right, so as she said my name is Michael Withrow I'm the director of solution architecture here at Twistlock So what do we do as a company? So really what we're focused on is as you look You know, you have the Docker ecosystem and you have enterprise needs and essentially We are the technology that really fits in between those two to bridge them together from a security posture perspective So what you really want to think about is that we provide a single pane of glass for really the Docker ecosystem And you know as you look at this is OpenShift and you know whether you use an OpenShift or whatever that technology is Maybe using an OpenShift registry and all those kind of things like that really think of as a single pane of glass for that That entire setup that you might have in that particular topology So look at a little bit of the vision from a product perspective and a company perspective You know as you look at it the value proposition for containers is is is is out there You know look at the DevOps the the immutability the statelessness that exists from a containerized ecosystem perspective You're we're seeing massive adoption across the globe really every every industry pillar every geo Is a massive adoption ring that's going on from containers One of the things that easily gets overlooked is that essentially as the security teams get integrated as DevOps or whatever is leading that particular charge Essentially, there is you know I'm taking hey look my traditional monolithic approach to securities and can I take that and apply that to containers, right? And then as I look at that is is containers a better opportunity For for security or less or whatever it is and and that's a lot of the conversation that we have with customer after customer as they're looking at You know Productionizing their containerized ecosystem the reality is as you look at it containers really change the attack vector that exists for your application when you move it to a container and Really what we're talking about is that with the right tooling essentially you can improve the security posture of that application By moving it to a containerized technology and I'll kind of walk you you know through our technology To show how that that really comes true Really what we're talking about from a capabilities perspective just a baseline everybody is that we're essentially talking about the fundamental characteristics of Containers, you know whether you're talking about the minimalistic state, right? Hey look I'm building a redis image right and essentially I have the redis application in there And that's essentially a singular focus from that particular perspective and it's very declarative, right? So I'm basically building a JSON file a Docker file or maybe a Docker compose file Or maybe I'm doing it through open shift and I'm having my open shift deployment, right? And I'm building a deployment for what that that image is gonna look like on this very declarative in that regard So it's repeatable and essentially every single time it gets deployed. It's getting deployed that way So very declarative in that nature and most importantly essentially a container by nature is immutable, right? You don't have agents in there making them stateful essentially their stateless and immutable in that particular regard Which like said those are the key terms I want you to think about as we kind of walk through what we do from a product perspective So when you look at it as well really driving that point home There's there's a couple of key security advantages that exist with a containerized ecosystem over a traditional monolithic, right? And really it really comes down to the automation, right? So so heavy automation integration with the CI pipeline process Maintenance through metadata and really what you want to think about is that when you look at key containerized deployments essentially what's happening is that essentially a traditional monolithic application Gets broken down, right? So essentially inside of a monolithic application say a three-tier application You might have you know three nodes in there representing each level of the tier and across each of those nodes You might have 15 applications in there, right? And that essentially makes up your application while in a containerized ecosystem you wouldn't have those three VMs You actually have ten containers each container representing that particular application right as it ties into that particular, you know overarching application in that regard and essentially each one is Autonomous in that regard and individually updated without you know impact across the other one across that tier And so when you look at traditional monolithic right essentially what you're looking at in that regard is that you have heavy dependencies You have you know, you have agents all these kind of things like that So now when you talk about upgrades, right? Essentially now you have to go through and you have to do regression testing You have to go through cmdb boards get downtime all these kind of things like that. You have to work through, right? Off magical perspective so when you look at it, right now start pulling back What are some of the security challenges that that containers actually bring to the mix as well, right? And so commodities of scale is the biggest thing, right? So we're commonly seeing as I look across Enterprises that we're talking to hey look I have 5,000 images I have, you know, you know 10,000 containers or 15,000 containers Which is you know five to eight times greater than what we typically saw in a virtual machine environment So that sprawl from those kind of things like that and not real Not real ownership for what is exposed across that so you have you know Legacy images those kind of things like that now I'm on version 100 of this image But I've still got one through 99 that exists in this environment. Those kind of things like that So the VM sprawl, you know the sprawl conversation has kind of come back to when you talk about containers and obviously a heavier Rate of change Instead of with traditional VM environments, you might see, you know a say a quarterly or a buy by annually type of update of that application Whereas with containers a daily weekly updates are Commonplace in that particular regard so a higher rate of change Across that ecosystem and then essentially the security responsibility moves, right? So now it's essentially further upstream Now it is in the hands of the developer and not necessarily falls in the infrastructure team, right? So in that regard you think application specific, right? And not that that edge based security conversation that typically fell in the infrastructure team And now it's making security an entire stream based responsibility Whereas developers are typically last the line when you talked about security So now when you look at it, right? Essentially When you look at containers, what is that what is the value problem of containers, right? Essentially by nature a container is secure. I mean it is portable, right? So essentially, I mean I do get away from that hypervisor conversation that that vendor lock in To x y and z maybe you're running a multi-cloud, right? Maybe you're running, you know In a hybrid cloud a public cloud or whatever it is Essentially, you know, when you look at our technology Essentially, we provide that portability as well because essentially not only does our technology protect the containerized ecosystem But essentially our technology is containerized technology as well, right? And so essentially what that means now is think of a rest api based product that really hooks into the entire ecosystem So maybe you deployed an aws or maybe you deployed on-prem and you're laying down open shift, you know v3.2 Inside of that inside of that environment Uh deploying an open shift registry, uh those kind of you know red hat based registry those kind of things like that Essentially we can provide a single pane of glass into into that environment And when you look at our product essentially, it's a lifecycle management based product Really providing cradle to scale security, right? So really starting in that ci pipeline process Maybe using Jenkins, maybe using drone, maybe using bamboo, whatever that might be from that particular regard Essentially we can integrate deeply in that environment So as those images are getting built before they get to the registry before they get attached to a deployment script and pushed out Into pods those kind of things like that we're going to integrate at that particular point And then as it does Get pushed into a registry and then now you have it in runtime out in a pod from that to the perspective We're going to provide a security posture of that entity all the way through all the different steps that it's going to take in its life cycle And we do all this without you having to give up any of your control Essentially all the data lives in your environment. So like I said before maybe you have a private cloud Where you deployed open shift in that private cloud and essentially now you would drop twist lock into that open shift environment Which is in your private cloud All the analysis that's taken place from a security perspective is happening in your environment So we don't pull anything out to to assess or analyze your particular environment We have we have many ways that we can support like I said talked about private and public We have many customers who are government air gap network segregated environments We fully support them through tar files as well from a product perspective So, uh, what do we do from a product perspective? Essentially as I alluded to before we are life cycle management So build through run And and one of the key things that we do and really where most customers reach out to us is around the vulnerability management Right. So so think of integrating into the build ci pipeline process where images are built We're going to assess and actually restrict the state of that image based on thresholds those kind of things like that And then as that image moves upstream into the registry Right, we're going to assess the vulnerability state the malware state Uh, you know, uh, the threat state of that image as it exists in the registry as well And then, you know, essentially now downstream and now you're running that inside of a pod inside of your open shift environment We can tell you the vulnerability state of that image and actually restrict that image Actually restrict that vulnerability from running inside of your open shift pod as well from that particular perspective We also tie in compliance, right? So think ci is benchmarks for containers Industry standards around compliance those kind of things like that. We can tie into that environment as well and restrict You know Say you have a security posture you want to maintain and essentially now someone you've done a good job of building a clean image Now someone tries to run that image say as root as an example, right? But you don't want that to run as root or they expose a certain port or ssh or something like that Now when they run it, we're going to assess that state from a compliance perspective See that it's outside of the compliance posture that you're trying to maintain And restrict that image from being run inside of your pod, right from that particular perspective And then we also tie in some access control mechanisms as you look at open shift There's a couple different ways that you could integrate from that particular perspective And then rounding it out from a product perspective, we tie in anomaly based detection across your running entities Through our runtime defense mechanisms So pulling the covers back a little bit further What you want to think about is that essentially how we work from a product perspective is that first and foremost We want to generate a bill of materials off of that image Maybe the first time we see that image is through the ci pipeline, right? So we have native plugins for jinkins and team city If you're not running jinkins or team city, we have an independent product called a twist lock scanner Which is really a shell script you call from a shell file from that particular perspective And that really allows you to integrate with any type of registry or any type of ci pipeline process That you might have like I said, you might be a bamboo shop or a drone shop or a circle ci or something like that And essentially all you do is you'd have a shell script would call out that that sh file and then it would basically On build it would scan and you'd pump out those results from that particular perspective Maybe the first time we see that image is actually in you know upstream in your registry, right? Like I said, as long as it's a v1 or v2 based registry, we can integrate it with it, right? So, you know red hats registry Um, like I said all the all the industry registries we can integrate with it And so as that image gets moved from your ci pipeline process into that registry, um, you know It's been there for a while, right? So we can assess the state of that image as well as it as into that registry And really what you want to think about is how we're doing that is essentially what we're doing is simply enough conducting a static image analysis Off of that json file, uh, really understanding, you know, what's the base layer, right? Is it debian based alpine based as an example? Um, uh, you know, what's the framework are you building a java app or a ruby app or something like that? And then in that read write layer that sits on top, um, What is it? What is your custom code set, right? What are the files you're sticking in there? What are the system calls those kind of things like that? We're kind of looking in there The idea is that we basically grab that, uh, those signatures and stash them in the mongo database that comes with the product Now that we have that information Or that you have that information in your environment because we is is not the term that I want to I want to Leave with you today is essentially like I said, everything sits in your environment Uh, is that we want to detect the cvs the zero days and the malware that exists against the entities that we defined in that image Right and to be a little bit more trans transparent in that regard Um, you think of packages, right? So the package manager in that particular regard Uh, we're going to look through and go through the packages. Maybe you have a tar file in there Where you're going to basically expose a package or install a package through that tar file Those kind of things like that. We can see that inspect that. Um, and then now we've we've stashed that So now we know hey look you have these packages as part of the image Whether that's they're installed through package manager or through some tar file in that particular regard And so now as that image goes through its life cycle Essentially now we bring in a real-time intelligent cve streaming service where we pull from a wide range of providers Think of all the different operating systems all the different languages from nist cis think the nvd database those kind of things like that Uh, we have some zero day. Uh, we have a we partnership a partner with a company called exodus Which does zero day mal hunting We have uh partnerships with some, um, ip and malware sites as well To to pull in that ip and malware data and then we have some pretty pretty aggressive machine learning algorithms as well That we kind of pump in Uh, as you as you kind of go through and that that lends to the life cycle, right? Because now from a scenario perspective You built a java based image. Uh, that has w get and um, um ssh expose or whatever it is from that sort of perspective That's that's your that you're deploying out. Uh, as it went through the ci pipeline process We assess the state of that and through the threshold based process You know, we got allowed to get posted to the registry but obviously now it's been in the registry for three weeks, right? Um, so so now over those three weeks, of course, you know These components have lit up and the package manager is told us that there's vulnerabilities We're going to pump into the environment and light up those those components across that ecosystem like a christmas tree in that particular regard Um, but essentially we don't even stop there from that to the perspective So i'll say whether or not you have it in the ci pipeline process that images in the registry It's been there for a month or now you have a running container that's been running for six months, right? That's where the cve service is going to come in and as a as a package becomes vulnerable Essentially, we're going to we already know from a signature perspective where that package transpires across your ecosystem and essentially all those images all those images attached to containers attached to pods We're going to light that up, right and then taking it further We actually have the ability to actually block those vulnerabilities as well Whether it's on a you're trying to build an image and when someone tries to run that image Think image integrity in this particular regard. So you have a scenario where hey, look you've built a clean image, right? And now you have a clean image on build But that image has now been living in the registry for three weeks So obviously over the three weeks a couple of the packages now have vulnerabilities So now when someone tries to do a deployment off of that image Essentially and you have the policy set to block Essentially, we will strict that image from being deployed into a pod because it has vulnerabilities in it So the idea from a dev ops perspective was that image would get thrown away because you don't upgrade or patch containers Right, you throw that container away and you deploy another container in its place or another image in its place Which doesn't have that vulnerability that someone your admin or whatever can do a OpenShift deployment off of into your environment And if you have an open running OpenShift pod, right? Think of us as a proxy that that you know works through the docker socket in that particular regard So if we need to restrict based on you have policy, you don't want to have a this application is very critical to you You don't want to have it out and running with vulnerable Vulnerabilities and so essentially you could move the policy to block and essentially in that regard we will restrict If now you have Java in that image and all of a sudden Java lights up Essentially, we would restrict that image, right? So think of in that regard we would kill that image because essentially it's adhering to containerized best practices You know if a container is anomalous has an anomaly in it or a vulnerability in it You don't patch it or upgrade it. You throw it away and build another one, right? Um, so essentially we can talk about you know what that means from a snare perspective But we allow you from a product perspective to one be alerted to the factors of vulnerability And if you choose to restrict that vulnerability So this is what that ci pipeline process looks like Essentially, you know think of a you know developer is going to be building an image Injecting in the pipeline. We're going to go through and the ci tool is going to notify us via the api or the plugin That hey look a scan needs to be initiated We'll conduct an ad hoc scan and publish the results back to that ci pipeline process And then essentially through there you can do with you know a threshold based failure, right? So think low medium and high from a cve scoring perspective So what you would say so maybe you have offshore developers or partners are giving you images You could pump them through this process and see if you even want to check them into your registry Maybe it's a trusted registry from that perspective And then so think of a scenario where maybe the the step to build the image is step three Step forward be it for us to scan it step five would be for us to publish the results and step six would be for you to push it You know down to your registry or to your downstream registry, whatever that mechanism might be Compliance uh, so here I'll kind of I'll kind of grease through this we can talk to this a little bit more Um, uh as we kind of get through but the idea here is that we can tie in cis benchmarks for containers And we can also tie in all of your industry standards Maybe you want to have application specific configurations that you want to adhere every time we deploy mongo It has to be deployed this way or every time I deploy tomcat has to be deployed this way We can enforce that from a compliance perspective through data sets You upload the data set to us and we allow in a very granular fashion For how you want to enforce that compliance posture, right? So through actions, right? So the action might be I want to be alerted When this particular configuration is tripped. Maybe you say that hey look, um, uh, or maybe it's an application specific configuration think Hey, look, I have a um a tomcat website. I want to make sure that every single time it's deployed It's deployed over 80 43 and not 443 as an example So now developer a new developer comes in uh, kind of missed that part of the the common engineering criteria So when they deployed it out, essentially they tried to turn it on over 443 You'd have a setting in here said hey look if this image is running off of 443 restrict it, right? I want to block that configuration Take it back to the developer to move it over to 80 43 and now they can actually do a deployment off of that Um, and we also in here also tie in image integrity, right? So what you want to think about here is uh, think cryptographically startifying images. So you would have a uh A scenario where hey look one as I'm building that image Now I know that that image is trusted. So I want to make that image trusted So I'm going to integrate with content trust and and and associate a shaw value as a tag with that image on push Maybe through my ci pipeline process or whatever it is So you would take your in this scenario take your your red hat registry and associate that with twist lock as a trusted registry And then we would in turn associate that with policy and say hey look now that you've built this gold image Essentially now what we're going to do from a process perspective is cryptographically Certify that and say that only these people can pull that cryptographically certified image And more importantly those people in that group can't backdoor or go around that policy And as an example, they don't want to use your trusted image They want to go to docker io and pull the swiss cheese version of that image. We would restrict that from a process perspective Uh, so access control, uh, you know, you look at open shift has some capabilities is there Really the key thing you want to think about here from a product perspective is that there's a lot of ways We can complement in that particular regard But really what we're kind of talking about in this particular regard is really providing a detailed audit trail off the back end Off of every single transaction that goes across that docker daemon. So whether it's a user-based access Mechanism or whether it's a privilege think pseudo or root in that particular regard We've provided that forensic trail of what transpired across that daemon as we kind of go through And now uh, you know now you have running entities right and so essentially we round out the product With our anomalous base detection And really the idea here is that we really bring uh, what we did in vulnerability management where we did that static image analysis You kind of see that here on the left From that particular perspective Um, and then we plus that up with the launch time metadata, right? When you kind of now you deploy that pod and now you have that running entity We're going to look at that launch time metadata Through that we're going to detect certain things right so think application specific detection here For our first leg of machine learning right and so what we're going what we're doing here This is very application centric. Hey look we detect htdbd. This must be an Apache file Hey, let's go find the config file figure what ports are associated with this particular deployment or this might be mongo Let's go look at these files and found this sh file or whatever it might be in that regard Maybe it's tomcat or redis or something like that Essentially, that's what the machine learning there is looking for application specific tags and then pulling that out So because the idea from a product perspective is we want to build a predictive model Because we're taking advantage of the declarative nature of containers And so by nature hey look you're saying hey look the purpose of this container is to run redis Right, so we're going to grab all that redis specific configuration and we're going to whitelist that topology out The key thing about this is that essentially we do that completely automatically on the back end from a product perspective And all you did from a product perspective Was tell us where your images were in this scenario All you would do is drop twist lock into your open shift environment And we would take it the rest of the way we would assess the vulnerability state And we would provide the anomalous base state of your entities as the running because we already know what they should be running Because we built a predictive model off of the images that are running inside of your open shift ecosystem And like said the value prop here is that we did that completely automatically without you having to do anything from a product perspective And then we also introduced a feature set we call twist lock advanced threat protection Which is a deeper set of machine learning algorithms So here think of a scenario where hey look you've deployed This image or this container into open shift, right? And so now there's open shift normal processes that run on the back end if we're auditing every single transaction Essentially what that would mean is that essentially we're generating a lot of white noise false positives in that regard Of traffic traversing across your environment. So through that we would see we would detect open shift No, no because we run open shift We pump it through our machine learning algorithms and we see that these are the normal processes And then we include those in the white list for that particular application So now what you're left with from a resultant perspective is really these those only true anomalies That you have to react off of right and then essentially that's ever evolving So as as diane was we were talking about before you guys just open shift just released 3.3 So if you go from 3 2 to 3 3 there's some changes in there And really what that means from our perspective is that we're going to pump in 3 1 3 2 3 3 into our machine learning algorithms Look at that look at that open shift environment in a running state And grab all the signatures off of that and then pump it through our intelligent stream service So essentially you get the benefit of that in a continuous state All right, so i'm going to show let me skip Time to limit it I would walk you through a little bit deeper But essentially how we bring this home and this kind of gets into the demo from that to the perspective The idea from an architecture perspective as I was alluding to before we are just a containerized based infrastructure So on the left is our intelligent stream service. I was talking about see all the different cv information You know, we're pulling from the red hat ovals Oval feed, you know from nist and cis You know, maybe it's java based or python or ruby or something like that Then we have our threat feeds where we partnered with exodus with proof point We're getting those zero day those those ip and malware data And then in the twist lock labs, uh, we're writing a you know, a deep set of machine learning algorithms Constantly enriching those and taking all the images that sit in docker io Taking all the you know, ecs and open shift and kubernetes and all these different environments and building them up and pumping them through the machine learning algorithms To assess the running state and and basically filter out all that operational noise So like I said, you're only left with application level anomalies from that particular perspective So on the right is your environment, right? Like I said, whether it's a public cloud a hybrid cloud a private cloud Maybe you're deploying it on just physical servers. The idea is that you have a docker damon that in that regard We're going to give you an sh file which has two tar files in there one for our console one for our defender You'll do a docker run off of those so to speak Um, and basically deploy them as containers on top of your docker damons in whatever capacity they might be in Right simply enough. We have uh, the console is an alpine based image running a node js console with the mongo database In there is where you obviously configure All of your policies out of the box essentially we have all the policies turned on and set to alert, right? So think of it as a as a as a starting point a guideline. Um, really we're thinking about it from a time to market perspective So essentially, you know out of the box All you have to do is basically deploy our product in your environment and then tell us where the registry is and tell us Where your containers are and essentially we'll start assessing that right? Um, but really we're just alerting that particular perspective But maybe you have a pc i based application or something Uh, a certain application that has pi data. You're really worried about Maybe you want to build a policy that's very specific to that application and move that to block because you're really worried about You know this security from that particular application We allow you the granularity to segregate out your applications your containers your images those kind of things like that Like said, you'll you'll suck in your users and groups. We don't really care what kind of identity you have To basically provide access control if you're using some other access control mechanism We integrate with that as well compliment Like said providing those audit trail those those kind of things like that And then, you know, your cluster management, right? So obviously kubernetes is a native capability for us So same thing since open shift sits on top of that that's where the tight integration that happens from our perspective So as you lay that environment down, we just implement We just integrate with the docker socket in that regard and function as a proxy in that topology But now that you've done that you build out all your policy The idea is that you cash that policy on the defender the defender wears multiple hats in this environment So think across your open shift deployment This would go on all of your slaves right from that to the perspective As you as you kind of go across so maybe you have like in my demo I'll show right if I get in this I basically have a three node Kubernetes cluster with the manager and two slaves in that regard So deploy the defender across that topology and so as I start deploying pods into that entity We're going to start assessing the state of those pods inventory And then assess the state of what we discovered in that inventory is kind of how it works So really that defender I'm like said is is one for configuration management assessing what's there providing that inventory data enforcing the policies that the console has set And then providing an audit trail off of all the transactions that happen across that daemon Regardless of what what level of transaction they are right? So think of a scenario where Hey, look, you've done your due diligence and and limited sudo from that perspective and built in all your access control policies for all the oc commands in that particular regard Now an admin tries to run an oc Policy they get an access denied from that to the perspective What does a normal admin do they're going to run a sudo oc? You know in that particular perspective to try to scale that out And if they do that essentially we've got them from a forensic perspective We would detail out that from a forensic trail perspective So essentially, you know, this is the easiest way that that you would look at it from that particular regard You know, hey look, you know, you have an orchestration manager You know, you have your your docker engine down with your orchestration agent in that particular regard We just integrate those defenders in that particular perspective For the through the orchestration if you use an access control But if you're just using vulnerability management runtime defense, essentially you really only need Us on the slave nodes in that particular regard to provide the vulnerability state And the runtime state of the containers in that particular topology So before I get in the demo, I will kind of pause And ask if there's any questions before I get into The demo from that particular regard No, so far there I haven't seen any questions yet So why don't you move right into the demo because we then we'll have some time after the demo would be great perfect so Um as we go through so this is our twist lock console From that sort of perspective. So what you're kind of seeing here is it's here I have a really simple open shift deployment, right with the red hat console and node one and node two in this particular regard I've already deployed twist lock on that topology and like I said out of the box twist lock is already You know starting to assess the images looking at the risk state of the containers that are part of that You know look at the access violations the system calls the process violations network file system violations that exist across this topology So the idea is that you know first and foremost, maybe you're you know through part of your open shift deployment You have a registry right you to integrate in the registry from that to the perspective And then now it's essentially a resultant of of your configuration, right? So from a flow perspective what you essentially have is we really broken the ui into three buckets First and foremost is configure here. I want to configure what I want to protect, right? So my users and groups Maybe it's I'm an LDAP environment or SAML. Maybe I'm Swarm or kubernetes or masosphere or open shift Essentially, I can integrate those in these are just I a config file turn on by default You know, um, uh, essentially you would toggle those on So regardless of whatever orchestration you have you would tweak the config file and then you would light that that capability up We have a couple of different ways to deploy the defender And essentially the native way is right through a curl command. You would run it directly on your slave inside your kubernetes cluster and so This is a good point to kind of pause and talk about We do have a large bank of customers that are already running open shift And one of the things that we're doing from a product perspective is going to make the We're going to generate some deployment scripts for twist lock inside of the open shift environment So it's not just, you know, a native install. It's actually a managed entity inside of your orchestra Open shift environment. So Essentially that'll be we're about two two to four months out from having that capability out Um, but essentially in the interim essentially think of it as a manual deployment inside of your open shift apology And then once we get the deployment scripts, it'll be really tie into the you know, the full capabilities of the open shift apology But the idea is that hey look here. I have those nodes and I've kind of scaled out the open shift environments On this particular regard, uh, you know, we have the ability so as you go for say, like I said, you're doing access control You would deploy in the master, but you want to do vulnerability management and compliance and uh, you know, uh Run time defense you would use that the node and that that particular perspective But you have those kind of deployed out from that particular capability Here's where you start building out policy. Um, so think kubernetes in this regard which kind of ties into the oc Commands in that particular regard But the idea is that hey look here. I have all the api calls and I can get very granular You know, do I want to allow or deny them access to those apis? Um, and here's that level of granularity. I was talking about you could start building out. Um, hey look here's application a Here's application b Maybe I segregated dev level. Maybe I segregated staging or prod. Um, those kind of things like that I start building out policies that line up to that and then I start segregating out who can do what And then audit trail off the back end So from a trust perspective, um, you know, the key thing is is you know vulnerabilities, right? So hey look here's the vulnerabilities. Um, what I can do is hey like maybe i'm building a java based application So simply enough and then by the fault you see that set to alert But maybe I want to tweak that the block those kind of things like that from a product perspective Here in compliance, uh, we actually go through and we have all the cis benchmarks So as an example, um, one of the things that I wanted to show was a real quick demo for you guys So I'll kind of restrict, uh, limit memory usage on a particular application think buffer overflow those kind of things like that And now 510 off natural perspective I'm going to set it to block and I say that out from a policy perspective So I'll kind of toggle back from natural perspective. So now I have this host here running off from natural perspective So now what I'm going to do is simply enough. I'm going to try to build another app Um, obviously this application that we've built obviously has a vulnerability in it So now we've set policy to say hey look, let's run that that that image I'm going to try to run that image from natural perspective and now it's going through and building it So what you'll find is when I go to status from natural perspective, um Is essentially when it's going through is essentially it's going to get blocked at container create, right? So once I go through and do a describe Off of that one, you'll see a line in there and says no I can't because um, uh So let me hold on let me do demo on With row six, uh from natural perspective and so now as it's going through What we're going to see is when it gets to that point essentially we'll see A note in here. I'll just do a refresh and essentially you'll see where we come in and block that particular perspective And see there's a successful poll now. I was trying to do a container create It started and essentially that's going to get blocked. Uh from a scenario perspective, right as we go through Uh, just kind of waiting for that to catch up All right, I'll give that a second But the idea is that essentially now, um, we have that blocking so as that deployment happens Essentially what you want to think about is when it gets to the point What actually does that actual deployment off that pod when it goes through that call goes through the daemon We're going to pick that up through the socket and assess that image and see that has vulnerabilities and restrict that from being done Right, so obviously every time the pod tries to push that every time the deployment scripts tried to push that into the pod We're going to restrict that right so open shift is going to continually try that obviously, right? So we're going to block that every single time in that particular regard Until you basically pull that out, right? So what I'll show from a scenario perspective is that hey look Um, you've basically attached this image and then simply enough I can remove that vulnerability You can see that deployment kind of going through so we'll kind of let this catch up Um And it's going to make a liar out of me. So it's created it started it still started in that particular guard I'm kind of waiting for it to catch up From actually the perspective and then I'll show because I know I have it Um what I wanted to show I'll have to pull it in here I don't want to show you guys I'll get it in there running in a second the demo gods always mess with me in that regard Absolutely doing a live demo Yeah, so um, but essentially what I'm getting at is that essentially when it gets to the point where it's actually building the container See it started the container. Oh wait, maybe I didn't have the policy set because I actually started the container in that regard Maybe I'm mis-setting the policy. Let's do that. So I have oh, I know why I did that because I did it on the wrong policy. So let me do Let me do 5 10. Let me set that to block And then let me save that and let me Toggle this one and go to 5 10 and turn that one off. So I don't break anything Um from that to the regard I'm going to save that so now To do the demo correctly. Let's just do another one right just for the essence of time Um, I'm going to build Another one And then you'll see because now that I have the policy actually set right You'll see when it gets to a point where So what did I build so that's what I built seven? Yeah, so then off that particular perspective Now we're going to go through now. We should actually go through when it gets to that point We'll see that actually restricted from a policy perspective So now kind of walking back through while that's cooking Essentially what we've done what we have here is that obviously you're looking across all your pods We can see the pods in here see the state of the pod the last commands that were ran across that pod Here's the first one that I kind of did from that regard I can pull up, you know, some compliance info. Obviously this container's running, uh, you know as root You know app armor is not configured set comp and limit limit memory usage, you know, obviously I checked 510 In that particular regard. I can see the host apology. Here's, you know So from our perspective, we're not really a host layer protection product But essentially we're from the docker daemon up, right? So as you have that docker daemon, you deploy Open shift on top of that docker daemon Essentially, we're protecting that up across that particular topology And you can see how the state of the host is running from that particular regard Think the network card think storage because if those get affected that affects the containers on the topology And then as we kind of go through, hey, look, here's the daemon the daemon configure files, you know Set comp those kind of things like that. Notice everything looks good Now we're kind of looking at the images as they exist across here's, you know on the registry Here's docker.io You know as they look across and what we bring in from a product perspective is that hey, look Here i'm now breaking down the vulnerabilities, right? And so actually go out to the nvd database You can see the state of that vulnerability But really providing eyes into the environment. So here's that image, right? Here's the compliance posture that image Here's the process info. Here's what we detected as part of that image This is going back to that whitelist I was kind of talking about Here's the packages we kind of determined that we're part of that You know as we go across to see this is a pretty big image in that regard And then really as you look across really the the cve perspective of that particular Package that's in that image as well You can see how they light up in that particular regard and then kind of from a configuration perspective where that image is deployed You kind of see that configuration data. So all across this you can see hey, look this one has 29 So I can go in here and see the vulnerability state You know go out to the nvd database and then do that So really what you're looking at is that all you've done is you've deployed a you've through your ci pipeline process Whatever that might be you've integrated in the registry. We've already added the registry in here So now you've dumped that image in the registry We're going to automatically assess the state of those images that sits in that registry, right? So here's that red hat registry. Here's basically 3.1 Um, and here's the state of those images in 3.1, right? And obviously 3.3 is better, right? From that to the regards to 3.2 3.3 as you move across We're showing the state of those those images that sit in those registry from that to the perspective And then like I said as you now is you as you deploy those images across the topology and now start deploying pods We're giving you eyes in the state of those pods across that open shift deployment So now I'll kind of take a breath and see if there's any questions Oh, it's it's it's really cool. And it's you know, it's interesting to see the the vulnerabilities in there in some of the open shift containers too And hopefully 3.3 is better I'm I've did a lot of work a while back with compliance and audit reporting and scanning for that you have any Output I mean I see csv, but like I'll be like a vulnerability report That you can so so how we do so right now in the product we are going through we're starting A ui remaps of some stuff will come out in that regard We haven't really finalized a plan in that particular regard But really the easiest way to answer the question is that Essentially throughout the product if you need to export anything out We really give you the ability to do a csv export so you obviously can filter So you get very specific information isn't just not a raw dump But really throughout the product It's just basically a csv export of the vulnerability state the compliance state those kind of things like that Well, that's really handy to have now if you can only make it look at all of the licenses for all of the module So that's a really interesting question. So we've actually So when you look at it, right? So we looked at you know when we sat down and we thought about this product, right? Essentially we looked at you know, where does it fit in the in the market, right? So obviously there's a lot of good products already out there that do hardware based assessment those kind of things like that You know think cloud cloud cloud passage tripwire those kind of things like that as we kind of go through And then we already have we have a great partnership with a company called sonotype Who does licensing integration as well right from that to the regard? So we said, okay. Well, hey, look, you know sonotype obviously does deepen the licensing So we kind of said well, we're going to stay in our niche from that particular perspective Yeah That's that was a bane of my existence. I'm looking for I've heard that from quite a few customers. So I know exactly where you're coming from Yeah, because I think in a new containerized world where people can you know bring containers in from lots of different places this security level of of auditing and And compliance reporting is really spectacularly necessary But also wondering whether someone has like a piece of software in their container that you know, your company doesn't You know doesn't have the license for Is another as always a big So, yeah So, um, so really the the easiest way to answer that is that so sonotype is one of our partners and they do have that capability And we've actually integrated We were finalizing the engineering of integrating our products together, right? And so if you were a sonotype based customer that would be one thing you could get because obviously they have the licensing The job of a specific information We have all the containerized ecosystem and really think of bridging those two capabilities together from a product perspective To really help answer that question. But obviously it's very, um, you know products specific in that regard So, um, let's did your demo complete? Yeah, so let me go back and see where it's at and see if we actually got that restriction Right and so obviously I demoed this all morning and it was working. There it is So now you can kind of see hey look air sinking pods skip fail to create running containers because it's got basically Basically policy blocked it right so now Essentially it is in a basically a looping state So open shift is basically trying to make that oc call to kick it and every sometime that call comes through Our integration with the socket. We're blocking that right so simply enough Um, I could go into here going to trust You know show kind of the flexibility of it right going to compliance going to this policy Um, check my setting going to 510 On that particular regard and then set that back to alert save that off and then when I go back into here, um, essentially Uh, you'll see that deployment kicks off Right from that to the regard and then open shift will go off and then that that's running In that regard. So now it just started on that regard and now it's off and running So does it add anything into the uh, because we're seeing it now from in the terminal mode and we're also seeing it on the twist lock page But if you've got someone if the it team Installs twist lock and i'm a developer. How does this surface in the open shift ui? You know if it's if i'm using it online So that's kind of what we're talking about is that so one of the things that we're working on from a product perspective Is actually bringing that to fruition right so so actually having some exposure in the ui I know my cto just had a meeting with red hat So those those conversations are going on as we speak Um, and we are working through that right so all the different uh vendors We're working to make sure that it's it's the most seamless experience as possible And so that's one of the things that we have to do right so like said as where we're at right now from a product perspective Is manual integration into your product But one of the things that we want to bring and we're working to bring in is that automation through the ui Yeah, perfect. Well, yeah, I think that's a natural next step So hopefully we can get that done and get you back and um show it servicing for Because I would think that a developer would go like well, okay wps, you know and You know so the the reality is is that how would work on the back end right and so so to bring that scenario home Kind of what we're talking about here is that i'm just kind of showing that reaction, right? Um, but what's going to happen is as that deployment goes through in the ui This is kind of what's happening on the back end through the daemon right and this is kind of what you're seeing in that particular regard As as things kind of go through and that would get exposed back in the ui in that particular regard that deployment failed Whatever it is and when they you know look in the logs, that's the kind of information They're going to see on the back end right so look at really kind of what I showed here is the back end integration And then what we need to build is that front end? Experience don't get me wrong. I'm loving that you can do this and you can block that I think that's a wonderful thing and I think anyone who's on the off side of the house is really loving it too So, um, I'm just trying to think visualize in my head where we would expose it in the ui for Yeah, so what I should do is maybe we'll follow up with you Diane is as as we get you know further down from an engineering cycle perspective in that regard You know, we could you know, that's what the idea is we'll schedule another call and show where we've you know Now six months later. Here's where we're at as an example Absolutely. I think that's that would be a great thing to do So, um, I see it's you've done a really good job and been very thorough because there haven't been it really too many questions here So, um, is I'm going to give everybody a last chance So maybe if you go back to your slides and put up your informational sides so people You have questions We'll kind of wrap this up a little bit There we go because We are almost at the end of our hour um If anyone has any questions Pop them into the chat or raise your hand and I'll unmute you But I I think you've done a very awesome job covering office and hopefully there will be no flaming containers out there Um afterwards and we'll post this video Um in the blog post at blogs at open ship.com shortly Probably take us a day or two to get them um cycle through And we have them all available and ready for you on our youtube channel as well So thanks again, michael and we will get you back in six months or hopefully sooner When it's more integrated into the and exposed for the developers So, um, thanks again Thank you very much for uh for getting me on I as opposed to talking to everybody