Compliance As Code With Open Policy Agent - John McCabe

you yeah so today I'm going to touch on a few topics kind of following on from the previous talk were he had a mansions for the increased sort of visibility of compliance in the accrete visibility of automation coming sort of as a result of of changes in the infrastructure world in the development world through DevOps so we're gonna be looking at a particular project that I've been using and as being increasingly widely used called open policy agents so--but about me a John McCabe I'm a software engineer Proofpoint I started off back when you would go and physically mount a rack and wire stuff up yourself before vm's before containers before anything like that you'd waste a huge amount of time and

then we got VMs and suddenly things were more sort of controlled and you could sort of do things more efficiently more quickly and then containers came along and you you got increased sort of at you ever be there as well and I've worked in automation at puppet and on the apache brooklyn project and specifically focused on this idea of automating and removing friction and sort of removing the human part from process where it's just where we're not great at following so proof point just got to do the obligatory thing we're hiring so we've a booth at in the stall if you want to kind of drop by and have a chat we're recruiting for quite a few roles here in

Belfast so let's start off by just asking the simple question what is compliance it's not hard it's following rules meeting standards and as time goes on organizations are facing increasing sort of numbers of regulations and requirements whether it's statutory or contractual or legal that they need to follow and that can impact infrastructure it can impact software you know it touches all parts of the organization's now so compliance with Walsh so you're you're compliant with a policy you know it's not hard a policy is just a rule so your organization has a set of security policies perhaps that identify the rules and processes and procedures that everybody in the organization is expected follow that if you run a service in

production you need to have XYZ sort of completed so that we know that we're sort of compliant with whatever sort of policies that are intentioned on us it's usually a wrapper a good sort of model of an organization's culture you know you can kind of see from the policies how an organization has evolved over time and quite often the approach is very manual it's very human there's like a sort of an oral tradition to policy and it's all sort of very sort of person-to-person is this okay we have policies we have compliance is this actually okay I would contend it's not that's kind of the the crux of the talk I'm going to have here I don't think

it's actually working particularly well sort of across most organizations you know the problem invariably comes down to you're seeing a disjoint in the rate of evolution between the sort of the gatekeepers of security and compliance in an organization and the technologies are increasingly sort of resulting in sort of speed and iteration and you know if things are increasingly and ephemeral you know it's very hard to keep track and security policy specifically in organisations quite often it's JIRA tickets it's spreadsheets it's you know Word documents wiki pages these aren't great things these are you're describing sort of very important policies and requirements human to human and that's very different because you can have misunderstanding you can have the

bandwidth as you increase the number of policies just it breaks down you can only remember so many things so what you'll find is new policies come out there's a flurry of activity everybody's very busy everything gets dropped okay you're compliant and then over time are you still compliant are there services that are sort of haven't been touched for a while because the project hasn't had people working on other they know non complaint there's a lot of gaps where things fall through and it's predominantly down to us having what effect could be a process driven approach to policy and compliance so processes square she processes human-to-human it's it's writing down instructions for other humans to follow in human languages it's

it's it's not reliable we're all human on humans make mistakes the best engineers in the world makes mistakes and they tend to be the worst ones because they tend to be the ones that you don't think you could have ever made like a slip you don't it doesn't register so so process-driven approach to sort of compliance and policy is not is not great so how could we fix it what can we do here could we write more spreadsheets effects the wiki pages I think we need to look outside of kind of what we've been doing a you know to this point and look at sort of advances elsewhere sort of in the ecosystem and specifically we're talking about policy

is code here where we want to sort of tick what we had described in our spreadsheets described in our wiki's and our JIRA tickets I'll actually turn that into code turn that into something that is objectively true and it's testable and it's something that you can't have ambiguity around so we should learn from DevOps so we've all seen sort of what's happened with through ops and infrastructure and dev and so on where they've kind of had this realization that their processes weren't good and also they had a lot of manual processes that were prone to mistakes and just just didn't scale especially with the evolution of the emergence of cloud and sort of kubernetes and so on it does not

scale so you know what did they do they double down on what they know best software development lifecycle so you you write code you don't write process you leverage version control you take advantage of that branching peer reviews sort of all these those things if change review flows you know a big part of like implementing a policy is that you need to be clear that everybody understands it it needs to have being sort of given a blessing by the InfoSec team the GIS team whoever is that all authority for codifying the sort of the policy that you want to enforce so it gives them an opportunity to act as a blocking reviewer so you can't actually

have a policy pushed out and enforced unless it's been approved by GIS this gives them control keeps the control there you also get sort of improved auditing and forensics things are know logged things are no time-stamped you can see who's changed something where they've changed it when they've changed it and if you build systems around this rather than building process you can wrap respectively go back and look at logs and look at where things happened you know it's it's it gives you a sort of foothold to improve how you implement policy across an organization and then of course automated testing automated deployments automation is a key part of this automation is just getting the human parts out of the process we still

need to figure out what policy means what being compliant means but we shouldn't have to be the ones that do it because we're not very good at it so one project that sort of can help us here is the open policy agent so open policy agent has been around I think since 2016 it is fully open source it as of April this year it was adopted into the CSC F incubator it's sort of sponsored and supported by sty resort of the company that the founders sort of created rather and and this is an important part it's a general purpose policy engine okay I know what can imagine kubernetes in the description the talk it's a general

purpose engine and we'll see what that how important that is the language the declarative language Rhaego which is based on data log it's not a general-purpose language it's designed for writing rules and rules or pauses okay it's it lets us do things sort of more straightforwardly that we could do in a sort of in a kind of another language and it's available either as well either as a demon or CLI sort of all implemented and go or a library which is increasingly becoming quite interesting in that you don't have to just die the service or rawness from the project you can call in the library via KITT into whatever you want make it into a

command-line tool making into some other custom service that you've written you can pull the core logic the parser and the evaluator and the interpreter pulling it into whatever you need that fits best for your organization and you're leveraging the same sort of policy engine that everybody else has regardless of how they're interacting with it so there's a couple of projects we touch on one of them later where we've seen people do that in the community so it has a pretty sort of simple IAM at the aim is to unify policy enforcement across the stack we've silos everywhere everybody does things differently that makes the job of you know security engineers extremely difficult because suddenly they need to

know everything the reason why cloud took off is because previously engineers deploying systems into production they needed to know everything they need so networking and physically racking things and all the different servers and the nuances the operating systems when neither will you ask came along and they started taking like a contract driven approach this and you you've suddenly removed the need to know how the sausage is being made behind the scenes you just take the contract and you use the contract and it's not your responsibility how that happens and it suddenly decouples you and frees you up to the deal so you kind of have the same idea we're sort of having sort of a

unified policy across the stack suddenly if you're using Terra forum if you're using share for pulpit or AWS or Google suddenly the way in which you implement your policies it's just one implementation the data structures might change but it's one set of tooling it's one set of processes you've only one thing to learn which is very attractive so yeah very simple at its core so this is a Popa so say you've a service that wants to use OPA to sort of you know make a decision about whether it's allowed to do something so it sends a query and the query just take the body OPA works on JSON objects so it takes a JSON object

it applies its rules to that object and it returns a JSON object that represents whatever another Lauer deny makes sense in your particular context you can configure what the response looks like for the allow case and that alike is so you would get in a query JSON object maybe it's a path the username and so on it goes to oppa oppa has policy so individual sort of policies are sort of stored in memory in oppa and it also has the ability to store additional data so what you can end up doing with the policies the policies can effectively be parametrized and data-driven so you could see a situation where you have one team perhaps is responsible for writing

policy and then another team decides how they ratcheted opera ratcheted down who gets apply tinsel so your query comes in the open engine apply checks all policies against us to see if anybody denies it so it just earns all the rules together so if anything says no then you get a response back to the service saying no you're not allowed and that can include contextual information so no you're not allowed because of X and because it evaluates all policies at the same time it's not you're not playing whack-a-mole you immediately get back you're violating because of X Y Zed ABC you just get at all so it's quite a nice experience for the consumer and your end user so the

community minute like there's quite a lot of significant companies already using this in in production that's why Netflix are using it for access control to their micro services chef use it to deliver I am capabilities in some of their products I believe and you've dozens of others using it to enforce sort of like you know policy in kubernetes or what have you like some of them was common use cases that you've seen or admission control which is what we're going to talk in the context of Kieran at ease authorization so people are using it in Kafka and micro services things that stuff you can hook it into palm and use it to sort of authorize who can and

can't log into a box or who can and can't get sue to access risk management you want to make sure that you know for example terraform there's an example we'll look out later where Tara forms notorious where it's easy to accidentally make a small change that results in loads of things getting changed you can sort of manage that risk by having a policy that says I'm gonna wit all the possible changes you can make and if you exceed a certain value then it's like no you're not allowed to do that we need to flag it up figure out what's going on so you don't accidentally do more than you think you're going to do DNA protection so

filtering for example in Kafka you can kind of restrict who can see wash and then yeah DNA for doing is just the same thing again so an example input so this this would perhaps be an example input from a micro service where even authenticated user Bob and they've they're you do they're interacting they've sort of talking to the micro service at the finance salary slash Alice path so that that's their context there and they've made a gap and we want to know if user Bob can see Alice's salary so previously the developer would have to codify that and put it into their into their service so if you suddenly decide we need to change the policy I need to get caller I need

to get JIRA tickets raised and an app it creative I talk to the product manager I need to get it could take weeks it could take months to get things done potentially so by decoupling the policy from that suddenly you're able to tweak the policy without having to go back and rewrite the services so a policy for that for example would be you know you're inputting the the input so the object that comes in is always referenced as as the M Posche you set the default so the rule is the allow so the default response for a rule in this case is false so it's like by default you're not getting access and then we've

been we've one instance of a rule and they lie rule where we're just some username we're just setting up the variable and we're making sure that the input method has to be cash really alert gets on the input path has to be Finance salary and username and what it's going to do here is this is gonna then sort of sort of initialize username with the value that you've just passed and then it's going to check to see if your user is the same as the username of the path so this lets you basically prevent you prevent you from looking at somebody else's salary and the thing with this is this is taxable you can suddenly write unit tests for

this that you can automate it and you can run and you you build up your metrics of all possible combinations of things as it's inching here you can get like a pretty good level of trust that a policy will do what you wanted to do so say for example you wanted to okay no the manager wants to see a user salary okay well we need to provide some additional data so this is where this there's this data object at the top so we're saying Alice doesn't have any subordinates Bob Alice works for Bob Betty John works for Betty and John doesn't have anybody working for them it's just another allow rule so it's the it's the same rule so this will both

rules are now going to get a value in it setting up the username that it's a GAF it's pulling out the username but now it's chatting to see if the input user exists as a yo exists as a subordinate to the requesting user so suddenly you've got the ability you know and if you're at you know that's quite a significant change in your policy enforcement what you've been able to do it with one or two lines of code in your policy engine because you and and it becomes very very powerful as just a sort of a basic example so using OPA you have a couple of options you've got a service you just run a daemon you have a CLI so you can

just take some JSON object on disk and just type them together you know and I come on the command line or at a pipeline and just use the can use the command line there's a full rabble when you're first starting to get used to it you can just open run and go in and experiment and flavor things and so on or that has met in the library and you can compare compose it into other things so one thing that sort of was reasonable there's a a project called contest guy garage Grove where he's basically pulled the whole opah policy part into a tool for specifically focused on testing in pipelines somebody has written a helen plugin so you can just do ham oppa

and you can do policy validation on your hound chart like for example it could be you must have certain labels you must not run as root and it's just ham oppa so you suddenly by making it available like that you've kind of you've not given somebody another process to interact with you've been able to tick the key part of it that you want and just push it into people's existing workflows transparently or as transparently as possible this is very important so okay we've got a way of codifying policy so that we're a little bit better but now we need to remember to do it we shouldn't we need to automate doing that it needs to be just

something that happens for free every time all the time so your various levels of maturity in terms of how people do this in organisations most people are using pipelines some organizations are starting to move towards get offs people are using like Argyll and things of that improving at ease there's there's different levels of sort of sophistication but they're ultimately doing the same thing they're just automating what was previously a manual process so for example here this could be an example of a just a Jenkins pipeline where you check out your your year this is so this is like this is it a terraform charge or terraform plan yes checked out there's an initial step where there's the unit asset it applies

the policy validation so if you try and do something in your ham jar or your in your tariff or pump that is non-compliant but whatever your rules are it'll just feel immediately it'll give you back contacts you feel because of this you don't need to go and talk to somebody and a security team to figure out what's going it just tells you do this fix it you'll be unblocked and then in this case it's passed so it's gone ahead and it's app light itself - dev you've mined you were getting promotions you do all the things that you would still want to do you still have control over what policies get enforced you still have control over you know manual

control with gear into production so it just gives you a lot of a lot of sort of power here you know then the policies itself you know you want to unit test policies so this is an example of a policy that's actually his job so the policies are packaged up with oppa and a hound chart so anytime you change policy everything gets pushed out so you can see it's building all the components it's testing the policies so there's a oppa task command and it runs unit tests and then it's testing and the testing can include you deploy oppa and then you've run a series of actual integration tests where it's like okay I have a policy that I can't pull from

docker it will try and spin up a pod or a deployment and pull from docker and they should be rejected and try and spin something up for an internal cache it should be allowed so you get this ongoing sort of verification rather than trust occuring and then for people using get up so this is an example of just a small sort of application so it was written in written to sort of run and get hope where you just attach the application to your organization so this is really hockey this is something and it's just true together but like you could see this being something that you just throw it across your organization it's clever enough to know what type of

project am i looking for am I looking at Tara for my love am i looking at how am I looking at something that might be using a secret in the wrong way and you could end up just having like you know one application that applies and does the right thing in the right context and just disappears into your workflow so you know and and that workflow is a big part of it you want to kind of disappear into the background for users so yeah it's never that simple that's all very easy very easy for me to say that it's binary sort of your life do something in order to do something reality is we have

non-compliance so you have existing non-compliance is usually one of the big ones you want to roll out a new policy you either stop the world and break it break your system for users that are non-compliant that point in time or you have to pasture and corral non-compliant services to get updated which can be time-consuming they may not even be resourced a particular instance so you need some way of dealing with the reality that you're not just dealing instant compliance so you want the ability to sort of have exceptions have allowances maybe some service needs to be non-compliant for a very specific business reason again you go that then goes through the normal processes of evaluation but the it gets

codified as an exception in the policy what when you do the exceptions the allowances you still do using policy is called Authority still remains with security you know they still are the ones that get to decide what hasn't allowed us what doesn't happen allowance you want visibility you get better visibility of it it's you can have it so that well first of all the single source of truth there is the repository you know the things that have an exception are in code in a repository so you can see them you can integrate sort of it into logging like Splunk so you can have a dashboard that shows you attempts to violate a policy where they're coming

from who's trying it sort of the usage of services that have an exception and are violating it's like they've said they were going to reduce and migrate across but they're still running and still being used so there's a lot of things you can get there to improve visibility and the ability to track how policies are being adhere to or not adhere to so it's just like you're ratcheting you know what you don't want to have happen is daliyah pushing at a policy because you need to wish for everybody to be ready you just push it out on everybody this compliant can never be can never go backwards anybody new must immediately be compliant and you just turn the heat up on people who

are currently compliant it's but very important that just speeds getting pause here so what does that look like in free burn at ease though so it's kind of cut off a little bit the side so criminales has this concept of an admission controller an admission controller is basically a gear keeper the sits in front of the API server and says whether you're allowed to create a resource or not create a resource so you know if you're interacting with kubernetes you know either BCI CD or the cube control command line or you you know you've got a controller rolling equipment at ease it talks to the API server it goes through the authorization on authentication you know you're all bot piece and then

it hits the admission controller so it hits mutating admission controllers which are say for example you you always wanted to tag certain label on every resource you could implement that in the mutating policy that it just happens for you and you don't know about it say for example you don't want anybody using darker but you have a cache it just automatically updates references to images and point some of the cops you have a lot of flexibility to do things there and then what we're talking about today is through the validation this is do you adhere to policy you're allowed or you're denied and what this does is it looks at the request of object so it

looks at the the the it's an admission review request this object and it checks it against the policies that you've defined in Opa and either lets you through or doesn't let you through and what's very nice about it is that if it does reject you it passes back very very actionable information you can pass by all the detail of you you're not allowed to do X because of why you should do this you know so that reduces the friction reduce you you don't want tickets coming out of these things so the keeper implementation as we have because as I say open is a general purpose we need to how do we get it working in kubernetes so it actually

works in kubernetes in conjunction with a sidecar called tube management and tube management handles it looks at configuration maps which is like blobs of yarrow that you can sort of create in kubernetes it looks for the creation of those and specific name spaces with specific labels and it washes them in to open as policies or it washes them in as configuration data so if you change a policy you can just keep control apply and you can save map it'll get synchronized with over postagens it also handles data replication so say for example you get a request and you won't ignore but say the service but you want to rule that kind of needs to take into

account ingress so you need a different class of object what cube management can do is handle replication of other resources in the cluster so you can write policies that are able to reference information that's external to the requests coming in so you can do quite complicated policies without the interact at the point of contact with OPA and the kubernetes is validating web who configuration all you're doing is saying if you get a request to create any resource that is picked off by you've a selector there so you can you don't just stand it everything you can select what are the types of resources that you want to get set if any of those come in send them to

the service and you can use mutual TLS to kind of secure the communication between the API server on your europa pods so you know similarly to what we saw before you know a policy could be quite simple so in this case the logic is reversed and that we're not allowing we're denying by default so in this case if any one of these rules so like as I say a rule every line is a rule if any one of those returned false will actually treat that as and allow to go through so in this case what we're looking at is pardon me we're looking to make sure that okay we're only looking at pods and deployments if you're

creating a cron job we don't care we were only looking at particular types of operations updates and creates perhaps we don't care about patches for some reason and then we've another rule that's being referenced here image from valid registry now the this value at the end that's the set that will get returned when that policy evaluates which we were intern returning to the deny and what that is that's the text you will information as to why you've been denied so you can make this data-driven which opens up the ability to kind of how separate you could have policy in one repo and the data that drives policy in another so here we're just saying yeah deployment and job

create and update and you're only allowed poll from docker and then the allowed images we're setting up the image variable container images is kind of one of the nice things that we have so we're running this rule container images and it's returning us a set of images okay so if you can imagine that we now have multiple images through that we're making sure that it doesn't match any of the registries so if for example it doesn't match anything there then we're using a novel and non-allowed registry so we go to the next line so message is no too so we pass a message value up which in turn passes up so that's that's an occurrence of a deny the container

images so particularly parlor disease are a thing in kubernetes they can let you prevent a pod from doing a thing and ultimately that's kind of good enough maybe because ultimately a thing will create a pod but the problem is if I am interacting and saying I want a deployment and the deployment isn't a pod but it contains a template for a pod what would happen with a pod security policy is that I'll be allowed to create the deployment but then it'll just sit there and I'll have to log it I'll have to connect and to keep control and have to check the state and I'll say oh it's stopping this you know qtn or creating

state because it's violating a pod security policy because we can kind of be more nuanced and OPA I've got two and two rules and they both get evaluated one is looking at the objects packed containers image which is going to return all the images that you would see at the pod level but the one below you're getting it at the tablet level so suddenly have one rule that's giving you pods deployments like we've examples resistant that are like basically giving you images from every single thing that could possibly contain an image pod security parlor or a pod to get hot security policies or sorry security contexts for say Ron is not roush sort of Ron as a specific user you no longer

have to define them on a per pod basis you can have it so that they get rejected for every possible object immediately which gives a very good and user experience and then you try to apply it so I tried to sort of create a deployment with darker it's fine it works as normal but if I try to use something from Google it'll come back and say you're violating because you've tried to go to a non-supported registry so it'll tell you I have what you've done wrong I can suggest how you fix it so criminales does provide some tools for security it provides like there's a whole range of admission controllers very specific purposes so one that will

ensure that you always pull images it will never use an image that's already on a box that can be useful say for example where you're using images from sort of secured registries where some service that's allowed to pull an image pulls it and another service that's scheduled on the same node you can get the image but it doesn't go through the authentication so this kind of stops that whole preventing you from exactly a privileged serve exacts or running his route image policies as there is a web hook that lets us restrict where you pull images from but the problem is you're left with that situation it only works on parts so you could create a deployment and you're

gonna find hidden away sort of through the troops you control the actual failure so it's not a very nice experience and then we have pod security policies again loads of security that you can apply but at the pod level using OPA lets you kind of pull it up a level so things fail as soon as we see them rather than sort of been hidden sort of behind the scenes so over policies again it's configuration rather than code in this case you're just defining the policy you full control over what that policy does that you saw in the first example we went from locking down users to allowing managers to go in you couldn't do that normally very easily

without having to go through a dev cycle we have more than just pods and you get logging ordering alerting that you don't necessarily get the others you can write your policies in such a way and there's extension points within OPA like there's a this decision logger decision logger interface where you can have it who can then maybe generate metrics so you can see what policies are violating new phone metrics of that you can generate a like send events to slunk Splunk every time a policy is violated so here the dashboard and Splunk and you can see who's actually not following the policy and you come back to the thing of consistent tooling you know we want it

to be more than just one one tool gatekeepers three which is in beta which will be getting quite soon even comes out-of-the-box with a standard library of kubernetes policies because ultimately we'll all want to do the same thing you know you've there's a lot of sort of duplication in terms of sort of what policies you want given is so gate keeper three and it's going to give you all the same things to see him but it's done in a kubernetes way the kubernetes native way so instead of just a pod with a sidecar it's nested C or D so a C or D in kubernetes is it it gives kubernetes full understanding of a particular data

object as a native kubernetes object so it no longer is just a thing that's running on kubernetes it's not a thing that kubernetes knows about so you can go cube control get get constraints get history and tablets and I will give you those because it knows what those things are so that's coming quite soon there's a lot of active development that mutation is going to be going into that yeah so you can like so the benefit of C or DS is because they're native every tool that works with kubernetes suddenly works now with your constraints so if you've like a UI or if you've some other system that kind of knows how to work with object resources and kubernetes

they just know work with us so complaints in terraform so sure most people kind of already terraform it's a infrastructure as code sort of tool for automating deployments in the cloud and so on and very widely used on the key part for us is it can I put JSON so we've something that we can kind of apply policy to so just for they have their own solution high score sentinel kind of primarily focused on hearty Corp I expect that will change over time but we can still use OPA with it so Jen the flow generally is a terraform plan convert the plan output to Jason apply your policy before you actually go through and sort of run it so for

example here is kind of cut off at the site so this is an example of where you make a change and that change could result in that could be a one-line change and if you do it it's gonna delete your VP sees it's gonna delete your your routes and you're like I didn't intend to do that like oh yeah that's not what I intended that's quite a common problem that people have as they sort of learn and understand terraform unless they're careful it can do things that you didn't expect it's doing exactly what it should do and what it's supposed to do but it can sometimes be a little bit of a problem for people

to spot so this policy for example is you can see there in the middle it's assigning widths here to different classes of operations so like Dilys that's costly you know we shouldn't expect you to do to it Elise obviously you could have different part flows with different policies applied for cases where you knew you were deleting services it can be specific to what you're trying to achieve so we've waited everything here and we're maybe only looking at a subset of resources and then the policy is just we're just making sure that the score so the aggregate score of all the waiting's is less than the configured blast radius which we set up to 30 below and we also

have another rule that you also can't touch the eye on so you can't change your eye on config when you do this so the blast radius it's just who scores a it's just basically another function or another sort of rule it's running through and it's aggregating all the resources in the object this is a little bit more complicated it makes sense after like you've played around with OPA a bit but ultimately what's this what this is doing is it's going through every single resource in your terraform plan it's going it's looking at the ones that you've included in your whitelist it's pulling out the widths associated with them and it's out it's summing all the weights and you're ending up with a

score that's representative of how how damaging your change could be and then the I am rule is just checking to see that you're not trying to change an iamb rule so it's checking for the occurrence of I am and if you've more than 0 being changed no go away and I'll let do it so you know this is what it would look like in practice I was gonna demo it but you won't probably see it on the screen terraforming it terraform plan out putting the plan and binary a show to convert the binary output to Jason and then you're evaluating your policy so the Ricoh the rules that we just saw in this rego file here the input is the

plant from above and what we're doing here is the data terraform analysis offs this is the output of rolling the policy which for the earth part is gonna be true or false you know you're allowed to do it you're not allowed to do it also in the analysis from running the policy you're gonna have a score so you can additionally see the score and you know we're getting it there and this would be something that you would just be against your pipeline you know just be something that would set and it would say you can't do it because you've tried to change these things changes are only low-impact this volume of things so you suddenly have more checks and

balances and stuff as being sort of done right so you kinda want compliance everywhere like it's the point of having a consistent system Kafka is another big example so Kafka has an authorizer interface there's an example or in the project of an implementation of an authorizer plugin it runs with Kafka and what it does is it all flows authorization to an OPA demon and it allows you to do authorization it allows you to do filtering so you can kind of run time by changing the configuration in the OPA demon you can sort of limit who can see what and what you know something you're starting to sort you can control very granular things that would have required development cycles

very easy to try so the documentation is very good it's it's getting better and better and better I think there was like version 15 just got released this morning I think I also put together I was going to do a live demo and I have a cat Accord a scenario that shows gatekeeper one so it it uses cat a quarter to spin off a turbine at ease cluster sets off the secrets Chris your certs deploys OPA deploys a policy and then shows you it running and failing and passing and you can just do that in your browser so cat a code as a projects a it's run out of London that's very very good so getting involved so subscribe to

their Twitter feed and it's worth doing the project on github they've quite so the main project is over the one that's seeing a lot of attention is we're out of the minute is deeper which is like the Canaries near the solution and they were very active slack group it's very it's it's very active um that is a varnish I finished on time amazingly unbeliev well thank you John are there any questions

questions for young you were very very from blue unbelievable alright give them another big hand thank you very much [Applause]