Hands-on Introduction to jsPolicy | Rawkode Live

[Music] hmm hello and welcome to today's episode of rockwood live at the raw code academy i am your host rockhood thank you for joining us today today we are taking a look at js policy faster and easier policies for kubernetes using typescript and javascript if you like writing everything as code today is a great episode for you before we begin there's a little bit of housekeeping please remember to subscribe to the channel and tick the bell to get notifications of all new episodes and i would also really appreciate it if you could like the video and comment and share with all of your technologist friends you can also support the academy with the various memberships options available you can find them at rockwood.live there is sandbox incubation and graduated a level for individuals and organizations and if you want to come and chat with nearly 600 technologists on cloud native kubernetes and everything in between join us in the discord available at rawcode.chat all right let's introduce today's wonderful guest i'm joined once again by rich and lucas from the loft team hey there how are you both doing it's really good it's good to be honest again david i always feel really bad when i throw that question out to two people and i just let them decide who's gonna go first and uh i really should just i should be better at this i should say hey richie lucas how's it going or maybe that doesn't really help i'll work on it uh okay so for anyone who doesn't remember you from last night as unfamiliar reviews from twitter etc can we just get some introductions and we'll start with you rich just because you're on the left and then feel free to hand that over to lucas yeah my name is rich burrows i'm a senior developer advocate at loft labs i've been with the company for about six months right now we work a lot on um making kubernetes easier for developers to use and also um people like platform engineers who own the clusters and are managing them so we are very interested in multi-tenancy self-service all of those kinds of things we really are looking to find the areas that um that people are kind of bumping their shins on and try to make them easier thank you for sharing lucas yeah lucas uh ceo of loft labs uh i have the pleasure of working with rich and all of these exciting topics and uh yeah we're really on a mission to you know help companies uh roll out kubernetes and expand their use from you know essentially right now they may have you know 10 or 20 or even 40 people having access to kubernetes and we help them to do you know essentially the leap to a thousand or even 5 000 engineers and more and obviously there's a lot of tooling and automation required and uh js policy uh which we're talking about today is you know one of the projects that we're working on the open source space that may make that transition a little easier awesome thank you for sharing uh for people that aren't familiar don't remember we had you on recently and we took a look at v cluster so you're kind of tackling a lot of these really difficult problems that people have with kubernetes the first one with multi-tenancy and we had an absolutely flawless demo so you have set the bar high i'm afraid and we're not going to accept anything less today and now gs policy which is tackling that really difficult thing where people are wanting to write more admission controllers and policies to restrict and segment access to their kubernetes clusters as well so um i'm curious about that what's the drive there like i mean these are really difficult problems are you just sitting down and going right what's painful for us and let's solve it for other people or do you got some other semantic videos in there yeah i think uh it is pretty much customer driven right we're in a lot of conversations with these platform teams that essentially run into these problems uh that have to manage kubernetes at scale for a large number of engineers and uh you know these conversations we just spot challenges and uh yeah i mean there are definitely pretty hard problems and with the technologies that we're building we're trying to make it as easy as possible for these platform team teams to essentially you know enable developers to more efficiently work with kubernetes and uh yeah they are complicated so big shout out uh to uh you know loft labs cto uh fabian who is actually grinding a lot of the code uh on this end you know we may come up with feature ideas and throw them uh at fabian but uh he's actually the brain of uh you know how do we actually implement this and you know make it work at scale so big shout out to him yeah he's fantastic we've also had some new engineering hires recently too so the team is growing awesome well maybe we can kind of address js bills they directly then uh i mean do you want to give the the pitch first like what is j-pop what is gs policy and why should people take no who wants to tackle that yeah i'm in the end yeah there we go the idea behind js policy is essentially uh writing policies uh as code and uh i think the the pain point that we saw was essentially that oppa with uh rigo has a language you know it's kind of like the default standard when you're looking at dynamic admission control in kubernetes everybody looks at open policy agent and they have to adopt rego uh as the policy uh language um which is not a you know touring complete programming language and feels uh you know very off for a lot of uh engineers and you know we were thinking can't we simplify that by essentially just taking a language uh that people know um you know but still assure that when people write these policies that they can maintain them very well that they can test them very well and that it's very integrated into what's what's already existing in terms of ecosystem and javascript and typescript just have such a vibrant ecosystem when you're looking at you know testing frameworks and cicd integration all these kind of things right it's pretty seamless because you know it's it's just such a popular uh language and such a you know vibrant ecosystem so yeah we tried uh javascript and that seems to you know uh reduce the complexity a lot in terms of you know if i write a policy in rego and i look like three months later i look at that policy right i'm having a pretty hard time understanding of what it actually does and i may be the person who actually wrote that policy right so i don't want to know how anybody else feels that has no clue about this policy in the first place and we hope to make that a little bit easier with javascript especially since most companies already have people that know javascript although they may you know not necessarily be part of the platform team they might actually be working on some fun and stuff but they are definitely qualified engineers uh in pretty much any company that know javascript yeah i'd add a couple things you know first first you don't have to be a javascript expert to you know write some basic policies with the tool um you don't have to go the type script route you know we'll we'll kind of show you the basics too um but you know the thing i like about it is that um it shouldn't have to be the platform engineers who write all the policies in my opinion you know there are some policies that you want to be maybe cluster-wide and and have those folks writing but i feel like um other people you know potentially should be able to contribute to and and you know you you could have platform teams i mean um application engineer teams you know writing policies or at least being able to read them and understand them right so so like even if they're not the ones writing them they can at least look at the policies and and kind of know what's going on yeah that makes a lot of sense i mean javascript i mean this has to be the biggest programming language in the world these days i think we're just the ecosystem is there and it doesn't matter if your background is from the front-end world of javascript world anyway because it's a c derivative language like it feels familiar even if you've never written that line of javascript before to go developers to see developers people's plus developers even java developers to a certain degree like the language primitives and constructs are mostly familiar so i think it's a really sensible choice for a tool like this and to go back to lucasy's point like i mean we've all been the person that looks at a bit of of code regal or not regal but then goes the hell is this code doing who what area wrote this and then you run the get log or whatever the guess show and you go oh it was it was me i've certainly been guilty of that many many times i think it's it's nice that i will have the potential and the ability to write policies and javascript because hopefully it solves that burden and that just that cognitive load that it takes to read and consume even yaml at times so very excited for today's session yeah when um when lucas first told me about the project and and showed me what they were working on kind of the prototype i i was immediately struck by how easy it was to just read the example policies and understand what's going on and and i'm not somebody who writes a lot of javascript you know so it's it's not like i i have more than a very you know very very fundamental understanding of it but you'll you'll see as we get into this that like it's pretty easy to tell what's going on i'm i'm worried no rich you've said easy twice and i'm like oh like that's that i shouldn't have read that for a demo whenever something goes wrong i'm gonna well you said it was easy and then hulk smash my computer so okay uh let's build up the home page uh because i think you know and i'll i'll put some words in the viewer's mouth here's like we've already mentioned regal and oppa and we've got kyvarno that people are familiar with and we've had episodes on in the past and there is this kind of comparison here do you maybe want to run through this and just tell people what is different in js policy versus these other systems yeah i mean obviously the the biggest different differentiator is how you define these policies in cavanaugh it's it's mostly ammo uh very very close to kubernetes um i mean in the end you know js policy and and overpower also have their uh crds right but the actual policy uh logic is not defined in in yamo itself um all of them support uh validating policies of course uh there are some differences regarding uh mutating policies uh you have a especially when you look at cavano that is pretty challenging to express changing an object in yaml right just because of the limitation of that declarative language versus you know in in js policy essentially it's mutating an object just as you would do in any you know kind of object oriented language right you have this json object and and i mean it's kind of funny you know kubernetes essentially we're writing yammer code but cube ctl under the hood converts everything to json right and before it sends it to the api server so what better language to uh you know manipulate these objects with than javascript i mean it's literally the javascript object notation so it's pretty straightforward to essentially you know have something like part dot spec dot something you know uh and then essentially write equals new value right it's really straightforward um and i think uh one thing that is really really different about js policy is uh a new type of policy actually uh we introduced a policy that is reactive um and we call them controller policies because they're kind of similar to actually writing a fully fledged kubernetes controller so essentially there are a couple of things that you cannot do with policies so let's say you want to have a network policy in each newly created namespace right that could be a policy in your company how do you enforce that this network policy is there right um that is really hard in admission control because uh in the regular admission control flow uh that is part of the namespace creation request right if i run cube ctrl create namespace uh the admission control happens first before the namespace object is actually persisted in ncd but the the network policy can only be created after then the namespace exists because it has to live in that namespace uh it's pretty challenging so what we do with controller policies is essentially introducing a new class of policies um or that essentially lets you react to kubernetes uh events so we have the event in kubernetes that is you know thrown namespace has been created right and you can watch it on that event and then essentially react to that um you know whether you check uh if a network policy has been applied within five minutes or so uh or if you you know created uh yourself throughout that controller policy there's you know there's so many options um and then another big difference is essentially js policy is based on javascript so you can make use of the entire tool chain regarding testing frameworks regarding package management right you can essentially there's npm.js the registry for npm packages you can essentially use any javascript or typescript library out there and just import that and use it in your javascript policy and we see that as a huge benefit to essentially share policy code um because right now you know you have to create something like a policy hub or something like that um to essentially share policies like a totally different ecosystem and it's a lot of work to build that up and to maintain that um but if we're already having npm.js you know that's essentially a given it's pretty straightforward for people to run npm publish and even publish things to their own internal registry and you know share things across teams and things like that uh you don't need to reinvent the wheel and that's a pretty interesting concept yeah most companies are going to already have that internal registry too you know so yeah i'm sold like you know the package management i've been having been able to distribute my policies via mpm and pull them in that way i think is super cool just because i'm familiar enough with that tulin and you know i think anyone who's written any kind of vernon open policies like testing them is really hard and been able to fall back on pretty mature testing frameworks available in the kind of node in javascript ecosystem i think is an absolute bonus and uh i'm really excited about controller policies and i want to see if maybe we could play around a little bit with that today uh you know mutating admission controllers are great for modifying the the ammo that's kind of being admitted but being able to actually react to that and deploy more or other things i think is really cool too so this is going to be fun now you pointed this out to me just before we went live so i figured we could run through a couple of these just to show people what the gs policy looks like what it's actually doing how it can how just how it works as a high level overview and then what we'll do is we'll dive over to my cluster and get all of this running so this is like your gs policy playground in a sense and that we have access to a policy here and a standard kubernetes object here and we have a traffic light system to tell us what is happening that i messed that up right no that's totally right um i really like starting with this deny default namespace one two because i feel like it's something that everybody's gonna understand right even people without a lot of kubernetes experience that you know we just don't want things to to get launched into that namespace okay so let's just run through this this policy then um we've got our api verizon and kind which i'm sure you're all familiar with we've got access to policy.js policy.com uh i've not seen v1b one in a while that's a nice flashback i'm glad to see that still kicking and then we've got king gs policy we've got metadata and then here's the guts of it so we have to tell it which operations that we want to apply the policy to which resources we've got the scope so i guess namespace and clusterwide would be my two options here and then we've got a javascript key that just has a conditional in it i mean i can just look at that and i understand what's going on which i think is a pretty exactly no yeah like i said when i first when i first started looking at this i was just almost shocked at how easy it was to like look at these things and understand them even as somebody who's not written really much javascript at all yeah so we're we've got a policy here that says whenever i create a resource any resource as designated by the star as the request object's namespace is default we just deny it i'm assuming deny is just a special function that blocks the admission of the the object so let's take a look we've got this ability here to then create an object this is in the default namespace and we get a deny nice and simple um so i guess the fix here is to change the namespace and it works that's cool i think it's a nice visual way to introduce people to the project and just understand what's actually happening although i suspect at some point in my career i'm going to start dropping actual real policies and payload and workloads into this than just using it as a standard check [Music] we've got people in the chat already asking if they can use this to break clusters on clustered um thanks russell you're always thinking ahead of me we've got a question from a madhan as well in the shot asking is this similar to plummy one do you want to tackle maybe the differences here um i i guess it could be seen like that oh sorry go ahead oh i was just gonna say i don't i don't know that palumi has um functions for for doing policy stuff but i could be wrong um i guess like i think lucas was about to say that it's it's maybe a bit similar in that you know you're able to use a language that is a standard language that you're already familiar with you know to to do the things that you want to do as opposed to like having to like learn a new language or a dsl or something like that yeah i mean from what i can see here i'll just add my kind of perspective to it you know i would probably use polomi to apply these policies to my cluster and then use js policy within the cluster to be the controller and the admission aspect of it so i think they work side by side together pretty well yeah the scope of palumi is a lot bigger yeah that's true all right let's take a look at this this add node selector so this is a mutating policy so this just means that when we apply something to the cluster we can use js policy to augment it or make it conform to whatever policies we have is that i've never had to describe mutated mission controls before does that does that make sense i think so yeah fixing resources right to make a match to policy is a good description yeah i think you know an example that people would probably be familiar with is you know making sure that things have labeled on them you know um um yeah cool well what i love right first and foremost it's not even the fact that this is a mutating policy right is that i have comments that live within the multilingual that are going to persist if i do a get or describe on this ammo right they're not going to disappear on me which is something that happens with the control plane when i apply yaml with comments they're all stripped out so i really like that assuming it works the way i think it does but what this admission controller is doing is uh we've got create again this time we're only mutating pods and if it has a label called add node selector true it says yeah it's like okay so it's adding the namespaces right that have this uh label so the namespace has that label then but again like in this demo we don't have a real cluster so it won't really check that if the namespace has that label oh right okay so the namespace selector says if the namespace itself has a label called node add selector true then what our policy is doing here is saying okay add a node selector through value test s2 and then mutate the object so it's just adding a node selector to the yaml so there we go it adds these fields here i like it nice and simple here's a question then that comes into mind so far what we've seen in these examples is that we use this javascript key and does that change the typescript for typescript or is it just a generic key and i could put typescript in here if i want like yeah that's kind of diving a little bit more into uh you know the architecture of js policy um essentially there are there are three different uh crds um that we're introducing um there's the js policy crd that you're seeing here and then there's the js policy bundle crd you know folks that may be familiar with javascript know about these like webpack bundles and things like that is essentially compressing javascript to you know embedding all the dependencies and making it highly efficient essentially optimizing the code um and the same thing happens when you uh take typescript and you compile it down to like vanilla javascript right because that's essentially what's running in your browser later on um and you know you there's two ways of creating a policy you can either embed the javascript logic like it is here and write it in line in the you know spec javascript um but you can also create that js policy bundle um and leave this uh spec javascript out and then js policy would take that bundle if you do the inline route like we do here what actually happens behind the scenes is uh when you're creating a js policy object like shown here um and the controller sees that spec javascript object it actually runs webpack and creates that bundle for you um so in the end what what the you know we're using v8 uh that's like google's um javascript uh execution engine that they run in chrome etc um and we actually let it run only the javascript djs policy bundle um but how that's created is essentially up to the user it can be you know created out of your typescript project with a custom you know ci cd pipeline or whatever that creates a bundle object and then the js policy or you do it in line and then essentially the controller would do that translation for you all right very cool um okay my next question does it support wasm bundles uh no not at this point it's actually a pretty pretty interesting uh route to go i think uh you know cube warden from the venture folks is pretty much focused on that it's kind of funny we were pretty much working at the same time on js policy when they were starting to work on cue board and we had a little chat before kubecon europe when they announced it and it was super interesting for you know to hear uh that they essentially had the same idea at the same time but went a different route because they're like they went the western road and we went like the v8 you know uh playing javascript road yeah cool yeah uh i think it just shows that there is a demand and a need that people want to be able to write their policies and languages that they understand and have the ability to do conditionals and loops and all these other things that we need so um yeah definitely okay you mentioned architecture uh we do have the architecture on the docs page if i remember is this the one yeah exactly yeah okay you can kind of see with these uh little red uh bubbles of what the actual execution order essentially is um you know when the when the cube ctrl request uh comes in at the kubernetes api server it's essentially calling a web book manager inside.js policy and that web book manager really looks at the js policy objects which you see here in green that the three green areas are essentially the crds that we're introducing the js policy j's policy bundle and nj's policy violations which essentially is you know more for reporting purpose to see you know what went wrong inside the cluster which policies were actually hit and denied and requests and things like that um and then js policy uh those objects essentially define uh you know which objects to target so they tell the web book manager hey whenever we're creating as we saw earlier pods or and you know uh things with certain uh labels that match you know those kind of things are defined in that js policy resource also operations that create delete you know whatever is sent to the kubernetes api server and then that web book manager essentially would call mutating validating web hooks as part of the regular you know kubernetes um you know api server request uh workflow um and it's essentially you know mutating uh web hooks are executed uh sequentially because otherwise you kind of have like a you know who wins both write the object right both mutated uh so they executed uh sequentially just like kubernetes does it um and then validating is executed in parallel because you know if one of them tells you deny it's automatically denied so we can speed things up by uh running them in parallel uh kubernetes does these weapon calls under the hood essentially and then objects are persisted in c or d in in cd which is step number three here and then there's the part that typically admission control frameworks don't address because it's outside of the scope of regular admission control workflow and that's these events that are created from the api server when new resources you know are added to lcd or altered or anything happens inside the kubernetes cluster um and that's essentially when these controller policies would be executed okay so we'll get hands on in just a second but i've got one question because i want to make sure i understood this a little bit correctly so js policy when running my cluster is registered as a dynamic admission controller like these other tools and that handles the mutating and validating aspect but you're actually setting is it just like a global watch on the kubernetes api server that says give me all changes and it goes through the controller policies uh i think we're watching on events here um okay so it's just essentially yeah all right okay let's is there anything else uh and the documentation you would like to go over before we deploy this to our cluster now let's get some hands-on experience with it sounds good awesome so should i do quickstart or the full guide install you got a preference now let's do a quick start that's probably the easiest one to get started with uh okay so it wants me to use helm to deploy to my cluster uh i think i have helm i do okay so we just do a standard install create namespace off we go hopefully won't take too long done so let's see what we've got installed on our cluster and i'm assuming it created just by that create namespace that we have a js policy namespace okay let's take a look so it's just a single pod this is the one that's running the v8 runtime and i'm assuming like an http server to receive the the the weapons from the api server right you can also run this in essentially more high available mode right essentially spin up more replicas and things like that that is also possible all right nice okay so validating we have a js policy validating where i put good meshing controller and i'm assuming the exact same on imitating site no interesting uh is that what we have to create a policy which is mutating you may see a change there all right okay so it's only at the mutating admission controller is probably only added when it's required okay i'll trust you for now so let's create our first policy so this is just the exact same one that we kind of had and uh the playground area let's just create this so we call this deny default i can't type what really can't type i have to look at the keyboard numbers in there my computer's struggling a little bit with me but we'll capture it would i this is the yeah this i kind of caught this during the playground and i wasn't sure where to ask a question or not but this is a name spaced but it's actually checking the namespace so if i apply this to the js policy namespace i mean in theory no object should ever come in where the request namespace is default right like you should yeah so how would i make this just a cluster white one instead of a namespace no no i mean so this essentially means uh when you're creating namespace resources regardless of which namespace so the js policy object is not namespaced right it's a cluster-wide resource ah okay i completely missed that right gotcha that makes more sense so let's apply it then it doesn't matter where the namespace is i should now just be able to run get gs policy i wonder if the pluto is going to be policies like that or like this there we go yeah you can also now run js policy bundle to actually see you know that that inline javascript has been converted to uh that pep on the in the end yeah yeah let me just learn how to type again though there we go okay so when we apply the js policy it's being compiled to an artifact and that's what we have in the bundle so if i run russia yaml on this i'm not sure what i did there oh because i need that first and this is the bundle which is just base64 encoded i guess that's correct yeah i mean i can't help myself but take a look now so oh it's binary encoded well it's not just the webpack output as like minified javascript it's actually stored as a binary file okay cool so i guess to confirm that our policy here is working in fact i'm sure i should just stick to those guys instead of making this option now so we've applied our policy and then we can see an action by trying to create some workload in the default namespace so here we're just going to say cube control create a deployment and genex where the image is this and our admission controller denies it saying we are not allowed perfect exactly what we wanted okay so uh should we start i mean do you want to dive straight into mutating mutation controllers or should i go take a look at some of the basics on the apply policies what interests you both yeah i think the the the coolest part is uh actually taking a look at the examples um so if you hit that uh github button uh that icon on the right upper corner um in the in the project itself there is a lot of you know example policies that really help to to get started with things you can either filter by feature or by use case um you can also dive into you know more typescript based stuff uh more advanced use cases okay let's take a look at feature first sjs policy features is that what that means that's right yeah correct okay yep uh where's your favorite rich um probably the mutating one all right i'm just gonna copy this my computer is about 20 seconds behind me but i'm sure it's going to catch up there we go okay so let's see if i can work out what this does without having to to ask for help in fact i'm going to delete the comment before i read it so we have a mutating policy that looks at the create and update operations of pods it's checking our annotations okay so we've got an optional so there may not be any annotations and if there's a required annotation no i'm confused okay so this isn't all right okay i'm just overthinking this this could be anything i could say that i have a requirement that all pods should have a rockered annotation that says live and if this doesn't exist this is just adding that annotation is that correct yeah right okay yeah in my head for some weird reason i was like we had some configuration that said all pods must have this required annotation labeled but add other labels and very much over complicating that for no real rhyme or reason so so now let's apply this to our cluster first and if we try this nginx deployment again um but if i just run this in the gs policy namespace then what we should see is our nginx pods all have the rockwood live annotation if i've understood this correctly so i'm going to describe pod js policy and if we scroll up nice we mutated that and added our rockwood live annotation it's nice it's it's not difficult it's just it's just javascript it would have been probably even less difficult if you hadn't deleted the comment too well i mean i've i'd i just wanted to see if i could work it out i know i know i'm just saying all right i'll read the comment i mean someone's putting a lot of time and effort to actually read and write these comments so it would be it would be rid of me just to delete it um so there's some really important information here that i can see already on scanner so we have the ability to like exit early with a deny or a low statement what happens if i have met denying allow and just let the function return is there a default action no it's essentially that web book would not do anything as part of your you know api server request okay and then we can call mute if we make any modifications i mean the api is is pretty simple then i allow beauty and off you go it's pretty cool right there a couple of more functions actually uh special functions obviously you can use anything built in in javascript uh and anything that is possible uh you know via any kind of you know javascript libraries which you're importing um but if you go back to the to the other tab uh with the documentation um you can expand uh functions down there on the bottom uh javascript reference and you see there there's more functions that we added um you know essentially for ease of use i think one of my favorites is actually lists and get um that is essentially to receive resources out of the kubernetes cluster so let's say you want to have a policy um that makes sure your ingress host names are unique right you can't just look at the current object coming in you actually need to take a look at all the ingresses at the cluster and uh you essentially need to retrieve those resources somehow you can do that with list for example ah very cool so i have like i i've got this very opinionated view of what getups means to me and my own production infrastructure and like one of the things i tried to emit from all of my repositories is uh domain information like this is rocco.com or this is staging.rocco.com uh i'm actually trying to rely on the component that provisions the cluster to inject a config map that has oh this is what your domain is for this cluster i could now use js policy with a mutating policy that says go fetch this config map pull out the value for the domain and inject that into all of the ingredients as i apply them to the cluster and just simplify my entire setup there um that is awesome i love it when i like do an episode like this and i have a real use case for the thing myself that i can go and just deploy it happened last time you came up with use cases that we hadn't thought of so it's really fun to to get you to take a look at these things because you definitely always have like some new takes that that we hadn't even um considered yeah i i just like to do weird stuff with technology but i'm really excited about this like i can i can already see this fixing my get ups because i just don't like putting that information in the repository and i'm not a big fan of my gaps tooling right and back to the repository with this information and this solves a lot of these problems because it's much more dynamic than i've had access to through things like caverno and opa in the past so it just opens up a whole bunch of these i i don't want to say like power user things but you know people that are going slightly off the beaten track and just want to do more exploratory experimental stuff having the ability to do those on the fly lookups um it's almost a superpower and i think i said that with v cluster too so user user when are me over with your technology i think i think there's uh there's an important thing in terms of being opinionated with tools like a lot of users i think especially newer folks want you to be opinionated they want you to you know have a an example architecture or you know to be able to tell them really in basic terms how to use the tool but you're always going to have those folks who have different use cases right and different needs um that like the the basic kind of opinionated workflow won't address and and so the tools also have to be flexible enough for people to be able to do the things that they need to do yeah yeah well set okay maybe we could cover a couple more of these functions and then we'll jump back to that examples and take a look at a couple more of the features so i see read files saying and immediately i'm thinking this can read a file from somewhere yeah so let's put in secret information from the secrets directory ah that's what and fetch things so i can actually pull remote urls from like guests or online etc and just pull them into accounts i guess that's the cool thing about having access to the javascript stuff what else do we see what's re-cue let's see that's a good question i think is that for controller policies yeah this one has another comment that should be a warning sign for me but just just move on go look at something else come back to this one oh yeah yeah this is for controllers you see that on the bottom right in line 30 yeah the controller policies are a little bit different because essentially they're not happening as part of your cube ctl request right they happen afterwards based on events and they're queued right um so essentially event comes in and then you have these policies which which are put in a queue and executed uh i think you know first in first out and then you can essentially add the the request to the queue again um you know there may be certain use cases where you want to reevaluate an event later on again okay cool let's pick one more just because i think it fits in with some of the stuff we've already done i see a warrant here we've seen deny we've seen a lot i guess warren allows it but logs somewhere that hey you may want to look at this in due course that's that correct that's that's exactly it nice intuitive yeah which is good all right let's pack i mean you know a situation you might want to use that in as you know something you're going to deprecate down the road you know and you want to start letting the developers know that you know they can't they can't depend on that thing being there anymore yeah 100 and something we see like sorry you go look at this you also show it in in cube ctrl right so the developer is in the end you know able to see that output as well which is pretty powerful i think cube ctl itself uh does it as well with like the deprecated ingress you know better resources etc they did that for a couple of versions before actually killing uh that api group off which makes a lot of sense because other otherwise you know not everybody reads the change logs every time they come out and make sense their page is long right yeah definitely i mean one of the things i think it fits in really well with this kind of tooling is that we've seen pod security policies being deprecated recently and the answer to that is to rely on tools like oppa and caverno and i'm assuming gs policy is that something that's available to people like do you ship a bundle that has the basic pod security policies for people to take advantage of or is that something that they would just write their own policies for to enforce the bits that they want i'm actually not sure if we have an example in there but we we may uh i know that we have something about escalating uh privileges of odds but i don't know exactly if we have pot security policy we do have denied privilege escalation so maybe that's a good one to take a look at and we also have a couple of well we've got one question and no mocking me in the chat uh there we go i know so i use my clustered automation for all these clusters just because it's it's so well written now um but yeah the ambassador ingress controller is currently broken since i upgraded the clusters to 122 because of a deprecation and i'm not getting warnings about that so yeah very funny no thank you for watching uh russell has got a question so what are the scopes the namespace filtering looks to be done by the javascript so it seems like namespace scope isn't required does the scope alter the shape of request object i think that's the same assumption i made that lucas kind of tackled earlier but do you want to add anything to that yeah i mean essentially you can specify within the policy really the scope of that policy right whether that whether you're restricted to a certain group or you restrict it to an api server version or resource in this case parts right and then a certain operation you can you know restrict it to a certain namespace and essentially we we won't even receive that request right when when you don't specify that so there's really like no overhead for any other resources only those resources that you actually specify that will be validated by the particular policy so it's pretty extensive filtering capabilities yeah so yeah you don't have the thing firing off you know when people are um altering other other kinds of resources yeah and i think of this uh highlight something that lucas said earlier just so it's not missed but all gs policies are cluster weighed right that i actually noticed that in my head so yeah okay yeah so all that means the policy object itself is cluster right right yeah exactly got it okay so uh we pulled up the privileged escalation one so this is an example of one of the particular policies that kind of disappears and there's a little bit of syntax in here that's uh it's just javascript isn't it so this is i'm going to try and explain javascript and i'm going to film a little bit but feel free to correct me here right so we're just saying that we want to take a look at all the containers and the pod um i love that it defaults to empty i mean can you apply a pod with no containers i'm not sure um the any containers definitely could be defaulted to empty and then this is the spread operator in javascript so essentially what we're seeing is get all the containers and all the inner containers and then we're using the for each iterator where we're just checking to see if the security context is set in any of them and then you've just got a deny message here that says that's not allowed like yeah i love that i can read these i've got to say it's pretty nice okay a question from frank is it possible to validate existing objects or resources i guess and get some size of report out of them yeah i mean you can you can actually take a look at uh you know what you've already denied uh in your example uh by you know getting the resource js policy violations uh which should give you an insight of you know what has been violated okay so that's a that's a new custom resource exactly yeah that's more for the reporting purpose there we go well let's take a look at this in the ammo i mean i'm assuming i could maybe describe it too oops too early okay oh there we go so we got a violation here so this is grouped by the policy itself and then the status is just a list of violations that it's denied and we've got a timestamp the object that was denied and then the message um so i think what frank is saying is like say i've got my production infrastructure already up and running and then i think okay i've watched the rockwood live episodes and js policies like the bee's knees so i'm going to go and deploy it to all of my clusters now it's not going to work on any of the resources within the cluster until we do a new update or reply or something like that or is there a way to retro respectively scan existing resources no that does not exist at this point uh but i think none of the policy engines do that uh right now i mean essentially everybody's just hooking into the regular mission control web you know web hooks and you know they're not being fired on existing objects and so unless you you know reapply them but i mean some some objects may i mean even if you were to just add an annotation to all objects like a random annotation you set it to true and then you remove it again you may have policies which only listen to create because they forbid create actions so there's no way to essentially capture everything i think yeah although i guess this is where your controller policies could come in i mean you could probably write something as a controller policy that dead that looked for violations and triggered updates via annotations or labels or something silly like that just to force them to go through the loop that's the segway we don't need to go into that right now but frank there are violation reports that are available here i'm assuming you could write tooling to pull those out and store them in prometheus or influx db or anything like that to get access to them frank is actually the author of the kyvernal policy reporter so i'm going to ask him nice i'm going to ask him now to add support for this so that we can take advantage of all that great tilling as well okay uh let's jump back to our examples let's see if we can pick maybe just one more feature and then we can see what we want to do after that so either we have nfm that you want to show off before i pick one randomly i think dependencies may be interesting to see does this mean it's going to use something from npm yeah exactly all right okay cool oh you're pulling on low dash i was expecting left pad you've let me down but uh [Laughter] let's see we've got a crate operation on pods only now we have access to a dependencies key on the spec where we can just list any npm dependency and then in the javascript we're just using low dash to do comparisons it's pretty neat the way that works i'm assuming then that when the gs policy is ingested that the web pack step is just pulling all those in and spinning at the bundle just like all the other policies yeah that's correct that's essentially where we separate a js policy from js policy bundle um and again like typically so this is actually a little ugly right because you're writing javascript within yammer right so the benefits i was mentioning earlier regarding tooling don't apply to this because like your ide will not you know show code highlighting fix your imports uh you know and your package.json cannot be scanned by dependency vulnerabilities and things like that um so the actual best approach is to create these bundles yourself and essentially just have a javascript object a package.json and essentially create these bundles and then create the js policy without dependencies and without javascript here but if you just want to test something on the on the fly um essentially this dependencies section allows you to do the same as the dependencies section in your package json okay so i'm trying to think how this would work and like i get up so it's likely that i would have my own repository with just like a npm in it that creates a javascript project i start to write all my policies as javascript probably each one being this one module and then i would configure my webpack to just compile each of those down and then i guess so you would just use ci cd to then genetically generate the gamma and apply them i'm not like do we have an example of what that would look like yeah if you go if you go to the docs uh there's actually a project that is set up for typescript but you could just write javascript in it as well you see that there are js policy sdk um like write policies yeah exactly uh and you can find that project on github and it's essentially a starter project right you can check that out um and essentially it has the you know webpack and everything configured so that you can directly you know get started right your policies are done i've got to say i have tried writing a webpack config in the past and failed every single time so i'm glad it exists so let's see what this looks like then okay so we've got policies and then annotations apply okay let's take a look at the namespace one okay so you just provide like the scale and oh i was just betting out to be a bundle no this is actually just uh the policy because the pun the bundle is created by webpack right uh from your source code that is in this index typescript file right um and the yaml code is essentially just uh defining the js policy like you know the scope of the policy right which objects uh is it mutating is it validating uh things like that and then the pop the bundle is created on demand okay got it does this show me how it's applied to the cluster yeah if you scroll down in the readme uh it it shows you the npm commands right so essentially you have the npm run compile which is doing the compiled step and the output of that compiled step is essentially uh you're going to see a policies folder so right now you just have a source folder and a test folder um it's going to create a policies folder which is on git ignore because there's no reason to version these you know i mean you saw that earlier right there um base 64 encoder and they're also g g sips essentially uh so that's why you saw like uh you know the binary kind of output earlier um you would actually have to unzip it as well so there's no reason to version that in git uh because it's essentially just your source code um and you can run that compile command and it would create that policies folder and that policies folder would contain the policy yaml and the policy bundle yaml for each one of the policies that has a folder in this you know source folder okay so yeah you can see all the different scripts configured in the the package.json there so kind of the standard compile the webpack bundling and then just the apply step here too so okay that makes sense it's actually pretty cool uh it's so we have this compile watch which uh you know whenever you change the source code or the policy yaml it would automatically you know kind of do the nodemon watching step um but you can also run the watch apply which would not only create the yammers but also run essentially cube ctrl apply go ahead which is pretty smooth if you're you know working in test cluster you don't even have to manually do the cubesat apply when you're writing your policies okay got it uh and you're just doing that through a webpack plugin right there the writing the yaml the policy gamble is that right is that what this does yeah correct okay yes exactly okay and in the end you know that policy uh that js policy code you know if you really want to do like get ups etc that is also something you could you know check in in your repository that you know uh policies folder um but again like it's it's not a requirement you could essentially also have a ci cd pipeline which essentially does that npm compile step and then runs keep see if apply is pretty much the same thing yeah i think some of them are seeing now with like argo and flux is that they're really providing the ability to run custom commands on these repositories as well so i mean we're almost at a stage where i can just hook this repository up to argo or flux and just say here go run an npm a compile apply and i'll just they'll just do it so okay very cool is there a if i click on the test directory is it going to have a test or is it going to be empty [Laughter] nice so yeah we can it's always nice to see an example of tests uh i like testing so i've been able to see how to do that yeah i'm definitely going to be forking this repository and stealing it for my ingress injection thing so very nice yeah it's also kind of nice you can see here that we're actually importing on the top the official like kubernetes client node right and we're creating pod objects down there and because it's typescript everything is typed uh which is pretty neat so we're essentially creating v1 spec you know for the pog um and things like that and it's essentially you know a lot more reliable than having uh only end-to-end tests where you apply yaml to your cluster and see if the policy actually works you know you can actually run very fine granular tests on pretty much each function that you're writing in javascript awesome uh okay i expect i expect there will be some folks who don't get this deep you know who will just use it and do you know things more like what you see in the examples and and that's totally fine but you know there is this you know extra power to to use all of the the tools that come in that javascript ecosystem if you if you want to get that deep yeah definitely uh we've got a question a question from jack in the chat who which i think i can even answer but he said why import whole of lodash here i mean the answer is because you can right like that's why we would do it yeah i mean in the end i think what tech is going to strip a lot away uh that may not be needed even uh i i'm not a webpack expert so i don't know how it works but i think they're doing a lot of optimizations in there it does a lot of tree shaking and magnification and a whole bunch of other fancy stuff that i've seen the compiler talks uh from conferences but i never paid enough attention to understand it but yeah i believe you're right okay uh the second thing i wanted to point out is uh sharing functions as well uh if you go to the policies folder again uh to the source folder sorry with uh that contains these policies you see this lib folder as well right on the one level higher um and that's essentially where you could you know define functions that would be used by several of your policies so typically your policies are grouped by resources right um so you have certain policies which apply to deployments you may have other ones which apply to parts right they have a totally different spec but you may want to check similar things you may want to prevent uh you know privilege escalation for example and that's part of the pot spec but you also want to check it for deployments and stateful sets and in lib you'll find a function uh which essentially can be shared and called from both of these policies essentially what does it end containers or meta yeah i think if you go to containers and then validate capabilities for example is one of them or validate images is another one right uh we're essentially running something here on the pod spec and this function expects the po prospect as an input right and if you're now going to the policies uh again uh so to your source to the source folder and then policies and then you'll see deployments and parts it's two different right we're validating them differently because we may run different checks on them right like deployments might have like eight other functions that need to be checked right uh they may have different annotations etc but both of them want to do that capabilities check um and then we can essentially if you go into validate pods for example um and then in the actual typescript code you'll see that we're running this validate container capabilities and we're passing the pots back to it right it's pretty straightforward yeah i like that being able to extract all the common functionality into shareable libraries to avoid duplicating code everywhere that you go and just having simple functions like you know validate namespace and validate container images yeah that makes a lot of sense um very nice i like that all right uh is there anything else to an examples repository you would like to show our audience before we finish up for today i think that was a lot of content already that's all right we have we have covered a lot um definitely a lot hold on let me pop us back over to there we go yeah there there is a lot here i mean i think uh just exploring the capabilities from the validating and mutating aspect and being able to bring that into my cluster and to be able to enforce the policies that i need and make the changes that i need it's like a great way just to get started and kick the tires on this and build out that tooling i really you know need to explore how to apply this to my cluster and get it started and i'm very excited to do that and we never really touched a lot on the controller stuff but there's just a whole bunch of different capabilities there that i could just have a field day with playing with i think there's you know potentially at least a couple of different types of users of this right like one is the people um like you who you know are very familiar with javascript and typescript and and want to get deep and and do those things but i think you know another set is the folks that were the reason that this got built which are the people who have tried to use some of the other tools and you know had difficulty for some reason and are looking for something where the policies are are easier to read and you know the thing that i want to emphasize is that you should be doing admission control whichever of these tools that you use right yeah like if you're not doing it at all and you're not doing it because you tried and it was hard um i really recommend taking a look at and js policy yeah uh you're 100 right like people need to be adding policies to their cluster especially with political deposits being deprecated there's a whole bunch of malicious things there that just need to be stamped out and js policy is a nice way of doing that i really like that capability of working with vs code getting syntax highlight and you know even using copilot i wonder how many of my policies i could probably write if i just let it try and do it for me and maybe that's funny sorry no i i was just gonna say i i hadn't even thought about that i had i don't have access to copilot yet so i haven't um i've got to be honest i'm so amazed by it and i know there's a whole bunch of ethical debates right now about whether we should be using it and such but i have found that it reads my mind like i can just write i want to start something with this and then it goes oh you're trying to do this thing and i'm like yeah i'm trying to do that thing so maybe in time as more people adopt js palsy and writing their policies we'll find that a lot of that co-pilot magic is going to work there and pod security policies be i can see that being distributed as an npm package and i'm leaving on top of that more and more best practices that are really hard to find in a kubernetes ecosystem and i think with gs policy lofts are now in a really unique position to be able to distribute that in a very consumable way that we haven't really seen before very exciting stuff and any final words before i let you both get back to your day just uh thank you so much for for another invitation that that's really great that we you know uh are talking about the a second project just like i think like a month later or so two months later it was a lot of fun talking about v cluster and it looks like js policy uh went smooth regarding the demo as well i have to see that i was since you mentioned the beginning i was kind of afraid you know is this gonna break something but it didn't this one this one is a little different because v cluster is something that had been part of our commercial pride product before we open sourced it right and so people have been kicking with tires on that for for quite a while but but js policy is is quite a bit newer um but it's always fun to to see or take all these tools david like you know you always come up with some things that um i hadn't even thought of and so it's it's a real pleasure to get to come on here well yeah thank you um [Music] it's just really i'm really happy with what i've seen so far and like i said i've already got a direct use case that i'm going to have to go and kick guitars with this this week so you know i'll be sure to to share my successes or failures but i'm pretty confident based on what i've seen today that it's going to be wonderful for for what i need um but unfortunately you to know how it goes and firstly for youtube like you've now come on and demo two projects that i really really like so like the third one's going to have to be phenomenal i don't know what you've got cooking in the kitchen but it's going to have to be good so no pressure i think we i think we may be taking a break from watching new open source tools for a little bit we we'll see but yeah because you're already tackling difficult problems like policy and multi-tenant like any time i have a difficult problem i'm just going to have to be like hey here's the thing please go run with it so we'll see all right thank you both again it was an absolute pleasure to work through this a very exciting tool i encourage everyone who's watched and followed along to go check it out and simplify your policy management on kubernetes i hope you both have a wonderful day i'll let you go now and i'll hopefully speak to you again soon have a good one bye thanks steven [Music] [Applause] thank you for watching [Music] you

Channel: Rawkode Academy

Views: 208

Keywords:

Id: oM1WU7HFCdA

Length: 71min 6sec (4266 seconds)

Published: Mon Sep 13 2021