1:16 Introduction and Welcome

1:16 Hello, and welcome to today's episode of Rawkode Live at the Rawkode Academy. I am your host, Rawkode. Thank you for joining us today. Today, we are taking a look at jsPolicy, faster and easier policies for Kubernetes using TypeScript and JavaScript. If you like rating 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

1:51 technologist friends. You can also support the Academy with the various membership options available. You can find them at rockload.live. There is Sandbox, incubation, and graduated, a level for individuals and organizations. And if you wanna come and chat with nearly 600 technologists on cloud native Kubernetes and everything in between, join us in the Discord available at Rawkode.chat. Alright. Let's introduce today's wonderful guest. I am joined once again by Rich and Lucas from the Loft team. Hey there. How are you both doing? Really good. It's good to be on again, David. I always feel really bad when I throw

2:16 Guest Introductions (Loft Labs)

2:30 that question out to two people, and I just let them decide who's gonna go first. And I really should just I I should be better than this. I should say, hey, Rich. Hey, Lucas. How's it going? Or maybe that doesn't really help. I'll work on it. Okay. So for anyone who doesn't remember you from last name, as unfamiliar reviews from Twitter, etcetera, 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

2:56 developer advocate at Loft Labs. I've been with the company for about six months right now. We work a lot on making Kubernetes easier for developers to use and also people like platform engineers who own the clusters and are managing them. So we are very interested in multitenancy, self-service, all of those kinds of things. We really are looking to find the areas that that people are kind of bumping their shins on and try to make them easier. Thank you for sharing. Lucas? Yeah. I'm Lucas, CEO of Loft Labs. I have the pleasure of working with Rich on all of these exciting

3:40 topics. And, yeah, we're really on a mission to, you know, help companies 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 or more. And, obviously, there's a lot of tooling and automation required. And jsPolicy, which we're talking about today, is, you know, one of the projects that we're working on in the open source space that may make that transition a little easier.

4:16 Awesome. Thank you for sharing. For people that aren't familiar or don't remember, we had you on recently, and we took a look at vCluster. So you're kinda tackling a lot of these really difficult problems that people have with Kubernetes. The first one with multitenancy, and we had an absolutely flawless demo. So you have set the bar high, I'm afraid. And we're we're not gonna accept anything less today. And now jsPolicy, which is tackling that really difficult thing where people are wanting to write more admission controllers and policies to restrict the segment access to their Kubernetes clusters as well. So

4:17 Motivation and Problem Space for jsPolicy

4:48 I'm I'm curious about the what's the 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 you got some other semantic videos in there? Yeah. I think it's it's pretty much customer driven. Right? We're in a lot of conversations with these platform teams that essentially run into these problems that have to manage Kubernetes at scale for a large number of engineers. And, you know, in these conversations, we just spot challenges. And, yeah, I I mean, there are definitely

5:21 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, yeah, they are complicated. So big shout out to, you know, LoftLab's CTO, Fabian, who is actually grinding a lot of the code on this end. You know? We may come up with feature ideas and throw them at at Fabian, but he's actually the brain of, you know, how do we actually implement this and, you know, make it work at scale. So big shout out to him.

5:59 Yeah. He's fantastic. We've also had some new engineering hires recently too, so the team is growing. Awesome. Maybe we can kind of address jsPolicy directly then. I mean, do you wanna give the the the pitch first? Like, what is j what is jsPolicy, and why should people take note? Who wants to tackle that? Yeah. I'm Indian. Yeah. There we go. Yeah. The other behind jsPolicy is essentially writing policies as code. And I think the the pain point that we saw was essentially that OPA with Rigo has a language. You know, it's kind of like the default

6:07 What is jsPolicy?

6:39 standard when you're looking at dynamic admission control in Kubernetes. Everybody looks at Policy Agent, and they have to adopt Regal as their policy language, which is not a, you know, Turing complete programming language and feels, you know, very off for a lot of engineers. And, you know, we are thinking, can't we simplify that by essentially just taking a language that people know, 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.

7:21 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 language and such a, you know, vibrant ecosystem. So, yeah, we tried JavaScript, and that seems to, you know, reduce the complexity a lot in terms of you know, if I write a a policy in Rigo 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.

7:56 And, I may be the person who actually wrote that policy. Right? So I don't wanna 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 may actually be working on some front end stuff, but they are definitely qualified engineers in pretty much any company that know JavaScript. Yeah. I'd I'd add a couple of things. You know? First first, you don't have to

8:28 be a JavaScript expert to, you know, write some basic policies with the tool. You don't have to go the TypeScript route. You know? We'll we'll kinda show you the basics too. But, you know, the thing I like about it is that 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 wanna be maybe cluster wide and and and have those folks writing, but I feel like other people, you know, potentially should be able to contribute too. And and, you know, you you could have platform teams I mean, application

9:05 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 kinda 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, with just the ecosystem is there. And it doesn't matter if your background is from the front end world or JavaScript world anyway because it's a c derivative language. Like, it

9:37 feels familiar even if you've never read a line of JavaScript before to go developers, to c developers, c plus plus developers, even Java developers to a certain degree. Like, the language primitives and constructs are are mostly familiar. So I think it's a really sensible choice for a tool like this. And to go back to Lukasys 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 idea wrote this? And then you run the git log or whatever the git

10:04 show, and you go, oh, it was it was me. I've certainly been guilty of that many, many times. So I think it's it's nice that I will have the potential and ability to write policies in 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 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

10:39 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. Uh-huh. I'm I'm I'm worried now, Rich. You said easy twice, and I'm like, oh, like, that's that is I shouldn't have said that for a demo. Then when something goes wrong, I'm gonna go, you said it was easy, and then Hulk

11:07 smashed my computer. So okay. Let's pull up the homepage because I think, you know, and I'll I'll put some words in the viewer's mouth here. It's like, we've already mentioned Regal and Opa, and we've got Qyvernal 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 wanna run through this and just tell people what is different in jsPolicy versus these other systems? Yeah. I mean, obviously, the the the biggest different differentiator is how you define these policies. In Kavana, it's it's mostly YAML,

11:10 jsPolicy Comparison with OPA/Kyverno

11:43 very, very close to Kubernetes. I mean, in the end, you know, jsPolicy and and OPAL also have their CRDs. Right? But the actual policy logic is not defined in in in YAML itself. All of them support validating policies, of course. There are some differences regarding mutating policies. You have a especially when you look at Kibana, 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 it's mutating an object just as you would do in any, you know, kind

12:03 Mutating Policies

12:28 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 YAML code, but kubectl under the hood converts everything to JSON, right, and before it sends to the API server. So what better language to, you know, manipulate these objects with than JavaScript? I mean, it's literally the JavaScript object notation. And so it's pretty straightforward to essentially, you know, have something like pod dot spec dot something, you know, and then essentially write equals new value. Right? It's pretty straightforward. And I think one thing that is really,

13:04 Reactive / Controller Policies Explained

13:07 really different about jsPolicy is a new type of policy, actually. We introduced a policy that is reactive, and we call them controller policies because they're kinda 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 wanna 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? That is really hard in admission control because in the regular admission control flow, that is part of the namespace creation request.

13:55 Right? If I run kubectl create namespace, the admission control happens first before the namespace object is actually persisted in etcd. But the the network policy can only be created after the namespace exists because it has to live in that namespace. It's pretty challenging. So what we do with controller policies is essentially introducing a new class of policies or that essentially lets you react to Kubernetes events. So we have the event in Kubernetes that is, you know, thrown. Namespace has been created. Right? And you can watch on that event and then essentially react to that, You know, whether you check if a network

14:36 policy has been applied within five minutes or so or if you, you know, created yourself throughout that controller policy, there's, you know, just so many options. And then another big difference is essentially JS policy is based on JavaScript. So you can make use of the entire, like, 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

15:20 because right now, you know, you have to create something like a policy hub or something like that to essentially share policies, like a totally different ecosystem, and it's a lot of work to build that up and to maintain that. 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. You don't need to reinvent the wheel, and that's a pretty interesting concept. Yeah. Most companies are gonna already have that

15:56 internal registry too. You know? So Yeah. I'm I'm sold. Like, you know, the package management and been haven't been able to distribute my policies via NPM and pull them in that way, think, is is super cool just because I'm familiar enough with that tooling. And, you know, I think anyone who's written any kind of open policies, testing them is really hard and been able to fall back on pretty mature testing frameworks available in the kind of node and JavaScript ecosystem, I think is an absolute bonus. And I'm really excited about controller policies. And I want

16:28 to see if maybe we could play around a little bit with that today. You know, mutating admission controllers are great for modifying the the YAML 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 gonna 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 JS policy looks like, what it's actually doing, how it can how just how it works as a high

16:50 jsPolicy Playground: Validating Policy Example

16:59 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 JS 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. Did I mess that up? Yeah. Really right. No. That's totally right. I really like starting with this deny default namespace one too because I feel like it's something that everybody's gonna understand, right, even people without a lot of Kubernetes

17:35 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. We've got our API version in kind, which I'm sure you're all familiar with. We've got access to policy.jspolicy.com. I have not seen v one beta one in a while. That's a nice flashback. I'm glad to see that still kicking. And then we've got Kang JS 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,

18:12 which resources. We've got the scope. So I guess names based and cluster wide 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 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.

18:49 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 a special function that blocks the the admission of the the object. So let's take a look. We got this ability here to then create an object. This is in the default namespace, and we get a deny. Nice and simple. So I guess the fix here is to change the namespace and it works. That's cool. I think it's a nice visual

19:34 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 gonna start dropping actual real policies and payload and workloads into this than just using it as a sanity check. But we've got people in the chat already asking if they can use us to break clusters on clustered. Thanks, Russell. They're always thinking ahead of me. We got a question from a mad hand as well in the chat asking, is this similar to Pulumi? Wondering if want to tackle maybe the differences here. I I guess could be seen like that.

20:10 Oh, sorry, Rich. Go ahead. Oh, I was just gonna say, I don't I don't know that Pulumi has functions for for doing policy stuff, but I could be wrong. Not to my knowledge. I guess, like, I 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 wanna do as opposed to, like, having to, like, learn a a new language or a DSL or something like that.

20:45 Yeah. I mean, from what I can see here, I'll just add my kind of perspective to it. You know, I I would probably use Pulumi 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 Pulumi is a lot bigger. Yeah. That's true. Alright. 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

21:10 Add Node Selector

21:19 can use jsPolicy to augment it or make it conform to whatever policies we have. Is that I've never had to describe mutating the mission controls before. Does that does that make sense? I think so. Yeah. So the same yeah. Fixing resources, right, to make them match the policy is is a good description. Cool. Yeah. I think an, you know, an example that people would probably be familiar with is, you know, making sure that things have labels on them. You know? Yeah. Cool. Well, what I love right. First and foremost, right, it's not even the fact that

21:53 this is a mutating policy, right, is that I have comments that live within the multilayer YAML that are gonna persist if I do a get or describe on this YAML. Right? They're not gonna 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 we've got create again. This time, we're only mutating pods. And if it has a label called add node selector true,

22:36 it sets Yeah. It's like Okay. So it's adding the the namespaces, right, that have this 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 the 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 test two and then mutate the object. So it's just adding a node selector to the

23:09 YAML. So there we go. 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. 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, you know, the architecture of JS policy. Essentially, there are there are three different CRDs that we're introducing. There's the jsPolicyCRD that you're seeing here, and then there's the jsPolicyBundleCRD.

23:36 jsPolicy Architecture and CRDs

23:55 You know, folks that may be familiar with JavaScript know about these, like, Webpack bundles and things like that. It's essentially compressing JavaScript to, you know, embedding all the dependencies and making it highly efficient, essentially optimizing the code. And the same thing happens when you take TypeScript and you compile it down to, like, vanilla JavaScript. Right? Because that's essentially what's running in your browser later on. 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.

24:33 But you can also create that JS policy bundle and leave this 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 when you're creating a JS policy object like shown here and the controller sees that spec JavaScript object, it actually runs Webpack and creates that bundle for you. So in the end, what what the you know, we're using v eight. That's like Google's JavaScript execution engine that they run-in Chrome, etcetera, And we actually let it run only the

25:13 Javis the JS policy bundle. But how that's created is essentially up to the user. It can be, you know, created out of your type TypeScript project with a custom, you know, CICD 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 would do that translation for you. Alright. Very cool. Okay. My next question. Does it support Wasm bundles? No. Not at this point. It's actually a pretty pretty interesting route to go. I think, you know, Cube Warden from the Rancher folks is pretty much

25:41 Does It Support Wasm Bundles

25:55 focused on that. It's kinda funny. We were pretty much working at the same time on jsPolicy when they were starting to work on. And we had a little chat before KubeCon Europe when they announced it, And it was super interesting for you know, to hear that they essentially had the same idea at the same time but went a different route because they're like they went the WASM route, and we went, like, the v eight, you know, plain JavaScript route. Yeah. Cool. Yeah. I think it just shows that there is a demand and a need that people want to

26:28 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, yeah. Definitely. Okay. You mentioned the architecture. We do have the architecture on the docs page if I remember. Is this the one? Yeah. Exactly. Yeah. Yeah. Okay. Yeah. You can kinda see with these little red bubbles of what the execution order essentially is. You know, when the when the kubectl request comes in at the Kubernetes API server, It's essentially calling the webhook manager inside JS policy, and that webhook manager really looks at the

26:38 Architecture

27:13 JS policy objects, which you see here in green. The the three green areas are essentially the CRDs that we're introducing, the jsPolicy, jsPolicyBundle, and then jsPolicyViolations, 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. And then jsPolicy, those objects essentially define, you know, which objects to target. So they tell the webhook manager, hey. Whenever we're creating, as we saw earlier, pods or and, you know, things with certain labels that match, you know, those kind of things are defined in that

27:59 jsPolicy resource. Also, operations that create, delete, you know, whatever is sent to the Kubernetes API server. And then that webhook manager essentially would call mutating, validating webhooks as part of the regular, you know, Kubernetes, you know, API server request workflow. And it's essentially, you know, mutating webhooks executed sequentially because otherwise, you kind of have, like, you know, who wins both, right, the object. Right? Both mutated. So they executed sequentially just like Kubernetes does it. 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 running them

28:47 in parallel. Kubernetes does these web calls under the hood, essentially. And then objects are persisted in c r d in in etcd, 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 etcd or altered or anything happens inside the Kubernetes cluster. And that's essentially when these controller policies would be executed. Okay. So we'll we'll get hands on in just a

29:26 second, but I've got one question because I wanna make sure I understood this little bit correctly. So jsPolicy 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 a global watch on the Kubernetes API server that says give me all changes and it goes through the controller policies? I think we're watching on events here. Okay. So it's just the Since yeah. Alright. Okay. Let's is there anything else in the documentation you would like to go over

30:01 before we deploy this to our cluster? No. Let's get some hands on experience with it. Sounds good. Awesome. So should I do quick start or the fill guide install? You got a preference? No. Let's do quick start. That that's probably the easiest one to get started with. Okay. So it wants me to use helm to deploy to my cluster. I think I have helm. I do. Okay. So we just do a standard install, create namespace, off we go. If they want it long. Done. So let's see what we've got installed on our cluster. And I'm assuming I created just by that

30:11 Quickstart

30:55 create namespace that we have a jsPolicy namespace. Okay. Let's take a look. Pods. So it's just a single pod. This is the one that's running the v runtime and the I'm assuming, like, an HTTP server to receive the the the Webex 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. Alright. Nice. Okay. So validating. We have a jsPolicy validating when I put good mesh controller, and I'm assuming the exact same on the mutating side. No.

31:49 Interesting. So is that what we create a policy which is mutating, you may see a change there. Alright. Okay. So it's only add to it. 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 in the playground area. Let's just create this. So we'll call it deny default. I can't type. What really can't type? I have to look at the keyboard number from there. Done. My computer's struggling a little bit with me, but we'll

31:59 Hands-on: Applying a Validating Policy

32:38 get through it. So would I this is the yeah. This I I kinda caught this during the playground, and I wasn't sure where to ask a question or not. But this is a namespaced, but it's actually checking the namespace. So if I apply this to the jsPolicy namespace, I mean, in theory, no object should ever come in where the request namespace is default. Right? Like, should this That's correct. Yep. So how would I make this just a cluster wide one instead of a namespaced? No. No. I mean so this essentially means when you're creating namespaced

33:21 resources regardless of which namespace. So the jsPolicy 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. But it doesn't matter where the namespace is. I should now just be able to run get JS policy. I'm wondering if the Pluto is gonna be policies like that or like this. There we go. Yeah. You can also now run jsPolicyBundle to actually see, you know, that that inline JavaScript has been converted to that pep bundle in the end. Yeah. Let me just learn how to type again,

34:02 though. There we go. Okay. When we apply the jsPolicy, it's being compelled to an artifact, and that's what we have in the bundle. So if I run dash o yaml on this. I'm not sure what I did there. Oh, because I need that first. Yeah. And this is the bundle, which is just base 64 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 a binary file. Okay. Cool.

34:56 So I guess to confirm that our policy here is working, in fact, I'm sure I should just stick with those guys instead of making this option there. So we have applied our policy and then we can see an action by trying to create some workload and the default namespace. So here, we're just gonna say kubectl create deployment NGINX where the image is this. And our admission controller denies it saying we are not allowed. Perfect. Exactly what we wanted. Okay. So should we start I mean, do you wanna dive straight into mutation controllers, or should I go take a look at

35:37 some of the basics on the applied policies? What interests you both? Yeah. I think the the the coolest part is actually taking a look at the examples. So if you hit that GitHub button, that icon on the right upper corner Mhmm. 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. You can also dive into, you know, more TypeScript based stuff, more advanced use cases. Okay. Let's take a look at feature first.

36:18 And SSJS policy features. Is that what that means? That's right. Yeah. Correct. Yep. What's your favorite, Rich? Probably the mutating one. Alright. I'm just gonna copy this. Computer is about twenty seconds behind me, but I'm sure it's gonna 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 I'm gonna delete the comment before we do 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

36:29 Hands-on: Applying a Mutating Policy

37:25 may not be any annotations and if there's a required annotation. Now I'm confused. Okay. So this isn't alright. Okay. I was overthinking this. This could be anything. I could say that I have a requirement that all pods should have a Rawkode 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 label that would add other labels and very much overcomplicating that for no real rhyme or

38:05 reason. So so now let's apply this to our cluster first. And if we try this NGINX deployment again, but if I just run this in the jsPolicy namespace, then what we should see is our nginx pods all have the Rawkode live annotation, if I've understood this correctly. So I'm going to describe pod jsPolicy. And if we scroll up nice. We mutated that and added our Rawkode live annotation. It's nice. It 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

39:04 I'd I'd I just wanted to see if I could work it out with I know. I know. I'm just saying. Alright. I'll read the comment. I mean, someone's spent a lot of time and effort to actually read and write these comments, so it would be it would be rude of me just to delete it. 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 met deny and allow and just let the function

39:32 return? Is there a default action? No. It's essentially that webhook would not do anything as part of your, you know, API server request. Okay. And then we can call mutate if we make any modifications. I mean, the API is is is pretty simple. Deny, allow, mutate, and off you go. It's pretty cool. Right. There are a couple of more functions, actually, special functions. Obviously, you can use anything built in in JavaScript and anything that is possible, you know, via any kind of, you know, JavaScript libraries which you're importing. But if you go back to the to

39:57 Special Functions

40:10 the other tab with the documentation, you can expand functions down there on the bottom JavaScript reference. And you see there, there's more functions that we added, you know, essentially for ease of use. I think one of my favorites is actually lists and get. That is essentially to receive resources out of the Kubernetes cluster. So let's say you wanna have a policy 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 in your cluster. Right? And you essentially need to retrieve those resources

40:51 somehow. You can do that with list, for example. Ah, very cool. So I have, like I I give this very opinionated view of of what get ops means to me and my own production infrastructure. And, like, one of the things I try to emit from all of my repositories is domain information. Like, this is rockode.com or this is staging.rockode.com. 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. Mhmm. I could now use JS policy with a mutating

41:28 policy that says go fetch this config map, pull out the value for the domain, and inject that into all of the ingresses as I apply them to the cluster and just simplify my entire setup there. That is awesome. I love it when I click through episodes like this, and I have a real use case for the thing myself that I can go and just deploy No way. Them. It happened the last time you came up with use cases that we hadn't thought of. So it's it's really fun to to get you to take a look at these things

41:57 because you definitely always have, like, some new takes that that we hadn't even considered. Yeah. I I I just like to do weird stuff with technology. But this I I'm really excited about this. Like, I can I can already see this fixing my GitOps? Because I I just don't like putting that information in the repository, and I'm not a big fan of my GitOps tooling right 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 Kiverrno and and Open in the past. So

42:26 it just opens up a whole bunch of these I I don't wanna say, like, power user things, but, you know, people that are going slightly off the beaten track and just wanna do more exploratory experimental stuff, having the ability to do those on the fly lookups, it's almost a superpower. And I think I said that with v cluster too. So user user winning me over with your technology. I think I think there's 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

43:01 to, you know, have a an example architecture or, you know, to to be able to tell them really in basic terms how to use the tool, but you're always gonna have those folks who have different use cases, right, and different needs 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. Well said. Okay. Maybe we could cover a couple more of these functions, and then we'll jump back to that examples

43:34 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 this is pulling in secret information from the secrets directory. Oh, that's what And fetching, so I can actually pull remote URLs from like guests or online, etcetera, and just pull them into account. I guess that's the cool thing about having access to the JavaScript stuff. What else do we see? What's re queue? Let's see. That's That's a good question. I think that's for controller policies. Yeah. This one has a big comment. That

44:13 should be a warning saying for me that just just move on. Go look at something else. Come back to this one. Oh, yeah. Yeah. This is for controller policies. 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 kubectl request. Right? They happen afterwards based on events, and they're queued. Right? So, essentially, event comes in, and then you have these policies which which I'll put in a queue and execute it, I think, you know, first in, first out.

44:24 Controller Policies

44:48 And then you can essentially add the the request to the queue again. You know, there may be certain use cases where you wanna 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 looked at. So I see a warn here. We've seen deny. We've seen allow I guess, one allows it, but logs somewhere that, hey. You may wanna look at this in due course. Is that correct? Yes. That's that's exactly it. Nice. Intuitive, which is good. Alright. Let's pick it up.

45:24 In, you know, a a situation you might wanna use that in is, you know, something you're gonna deprecate down the road, you know, and you wanna 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. Need to look at this. You also show it in in kubectl. Right? So the developer is in the end, you know, able to see that output as well, which is pretty powerful. I think kubectl itself does it as well with, like, the deprecated ingress, you know, better

45:58 resources, etcetera. They they did that for a couple of versions before actually killing that API group off, which makes a lot of sense because other otherwise, you know, not everybody reads the chains logs every time they come out and makes sense their page is long. Right? Yeah. Definitely. I mean, one of the things I think it fits in really well with 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 OPA and Caverno, and I'm assuming JS policy. Is that something that's available to people? Like,

46:31 do you ship a bundle that is 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 bets that they want? I'm actually not sure if we have an example in there, but we we may. I know that we have something about escalating privileges of bots, but I don't know exactly if we have pod 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 oh, we've got one question and

47:10 no mocking me in the chat. There we go. Hi, Noah. So I use my clustered automation for all these clusters just because it's it's so well written now. But, yeah, the ambassador ingress controller is currently broken since I upgraded the clusters to one twenty two because of a deprecation, and and I'm not getting warnings about that. So yeah. Very funny at all. Thank you for watching. 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

47:48 object? I think that's the same assumption I made that Lucas kinda tackled earlier, but do you wanna 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're to an API server version or resource, in this case, pods. 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. It's

48:29 only those resource that you actually specify that will be validated by the particular policy. So that is pretty extensive filtering capabilities. Yeah. So, yeah, you don't have the thing firing off, you know, when people are altering other other kinds of resources. Yeah. And I think I'll just highlight something that Luca said earlier just so it's not missed. But all GS policies are cluster wide. Right? I took a note of that in my head, so yeah. Okay. Yeah. So all the policies policy object itself is cluster wide. Right? Yeah. Exactly. Got it. Okay. So we pulled up the privilege escalation

49:06 Privileged Escalation

49:08 one. So this is an example of one of the pod security policies that kind of disappears. And there's a little bit of syntax in here that's that's just JavaScript, isn't it? So this is I'm gonna try and explain JavaScript, and I'm gonna feel measurably. Feel free to correct me here. Right? So we're just seeing that we want to take a look at all the containers and the pod. I love that it defaults to empty. I mean, can you apply a pod with no containers? I'm not sure. The any containers definitely could be defaulted to empty.

49:09 Policy Violations Reporting

49:40 And then this is the spread operator in JavaScript. So essentially what we're saying is get all the containers and all the other 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 just got a deny message here that says that's not allowed. Like yeah. I love that I can read this. I've gotta say it's pretty nice. Okay. A question from Frank. Is it possible to validate existing objects or resources, I guess, and get some phase of report out of them?

49:41 Spread Operator

50:19 Yeah. I mean, you can you can actually take a look at, you know, what you've already denied in your example by, you know, getting the resource JS policy violations, 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. Vial there we go. Well, let's take a look at this in YAML. I mean, I'm assuming I can maybe describe it too. Too early. Okay. Oh, there we go. So we got a violation here. So this is gripped by the

51:13 policy itself, and then the status is just a list of violations that is denied. And we've got a timestamp, the object that was denied, and then the message. 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 Rawkode live episodes and jsPolicy is like the bee's knees, so I'm gonna go and deploy it to all of my clusters now. It's not gonna work on any of the resources within the cluster until we do a new update or apply or

51:46 something like that, or is there a way to retrospectively scan existing resources? No. That does not exist at this point. But I I think none of the policy engines do that right now. I mean, essentially, everybody's just hooking into the regular admission control web Yeah. You know, webhooks and, you know, they're not being fired on existing objects and set 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.

52:21 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 did 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. But that that's the segue. 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

52:50 Violation Reports

52:55 to pull those out and store them in Prometheus or InfluxDB or anything like that to get access to them. Frank is actually the author of the kivernal policy reporter, So I'm gonna ask him Oh, nice. Okay. Gonna ask him now to add support for this so that we can take advantage of all that great tooling as well. Okay. Let's jump back to our examples. So Let's see if we can pick maybe just one more feature and then we can see what we wanna do after that. So either of you have anything that you want to

53:14 jsPolicy SDK and Development Workflow

53:27 show off before I pick one randomly. I think dependencies may be interesting to see. Does this mean it's gonna give something from NPM? Yeah. Exactly. Alright. Okay. Cool. Oh, you're pulling on low dash. I was expecting left pad. You've let me down. But well, let's see. We got a create 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 Lodash to do comparisons. It's pretty neat the way that works. I'm assuming then that when the JS policy is

54:14 ingested, that the Webpack step is just pulling all those in and spinning out the bundle just like all the other policies. Yep. Yeah. That's correct. That's essentially why we separate a JS policy from JS policy bundle. And, again, like, typically so this is actually a little ugly. Right? Because you're writing JavaScript within YAML. 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, you know, and your package JSON cannot be scanned by dependency vulnerabilities and things like that.

54:55 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 wanna test something on the on the fly, 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 I get up. So so it's that I would have my own repository with just, like, NPM in it that creates a JavaScript project. I start

55:36 to write all of my policies as JavaScript, probably each one being its own module. And then I would configure my webpack to just compare each of those down. And then I guess I you would just use CICD to then genetically generate the YAML and apply them. I'm not do do we have an example of what that would look like? Yeah. If you go if you go to the docs, there's actually a project that is set up for TypeScript, but you could just write JavaScript in it as well. Mhmm. You see that there are JS policy

56:07 SDK, like, policies. Yeah. Exactly. And you can find that project on GitHub, and it's essentially a starter project. Right? You can check that out. And, essentially, it it has the, you know, webpack and everything configured so that you can directly, you know, get started, write your policies with them. I've gotta 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 got policies and then annotations apply. Okay. Let's take a look at the namespace one.

56:54 Okay. So you just provide, like, the scale and oh, I was just betting that to be a a bundle? No. This is actually just the the policy because the the bundle is created by webpack, right, from your source code that is in this index TypeScript file. Right? And the YAML code is essentially just defining the JS policy, like, you know, the scope of the policy. Right? Which objects is it mutating? Is it validating? 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

57:33 cluster? Yeah. If you scroll down in the read me, it it shows you the NPM commands. Right? So, essentially, you have the NPM run compile, which is doing the compile step, and the output of that compile step is essentially you're gonna see a policies folder. So right now, you just have a source folder and a test folder. It's gonna create a policies folder, which is on gitignore because there's no reason to version these. You know? I mean, you saw that earlier. Right? They're base 64 encoded, and they're also g g zips, essentially. So that's why you saw, like, you know,

58:12 the binary kind of output earlier. You we would actually have to unzip it as well. So there's no reason to version that in Git because it's essentially just your source code. 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 on the the package dot JSON there. So of the standard compile, the

58:47 webpack bundling, and then there's the apply step here too. So okay. That makes a lot more sense. Is actually pretty cool. It's so we have this compile watch, which, you know, whenever you change the source code or the policy YAML, it would automatically, you know, kind of do the note one watching step. But you can also run the watch reply, which would not only create the YAMLs, but also run essentially kubectl apply, right, which is pretty smooth if you're, you know, working in test cluster. You don't even have to manually do the kubectl apply when you're writing your policies.

59:23 Okay. Got it. And you're just doing that through a webpack plugin. Right? The the writing the YAML, the policy YAML? Is that right? Is that what this is? Yeah. Correct. Okay. Yes. Exactly. Okay. And in the end, you know, that policy that JS policy code, you know, if you really wanna do, like, GitOps, etcetera, that is also something you could, you know, check-in in your repository, that, you know, policies folder. But, again, like, it's it's not a requirement. You could essentially also have a CICD pipeline, which essentially does that NPM compiled step and then runs kubectl

59:57 apply. It's 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 could just hook this repository up to Argo or Flux and just say, here, go run an NPM up up compile apply, and that would just that would just do it. So okay. Very cool. Is there a if I click on the test directory, is it gonna have a test, or is it gonna be empty?

1:00:27 Oh, sure. Has, one sample test. That's one sample test. Nice. So, yeah, we can it's always nice to see an example of tests. I like testing, so I've been able to see how to do that. Yeah. I'm definitely gonna be forking this repository and stealing it from my ingress objection thing. So very nice. Yeah. It's also kinda 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, which is pretty neat. So we're essentially creating

1:01:03 v one spec, you know, for the pod and things like that. And it's essentially, you know, a a lot more reliable than having only end to end tests where you apply YAML to your cluster and see if the policy actually works. You You can actually run very fine granular tests on pretty much each function that you're writing in JavaScript. Awesome. Okay. We got 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,

1:01:36 Sharing Logic with Policy Libraries

1:01:39 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 wanna get that deep. Yeah. Definitely. We've got a question also Oh, I'm sorry. I didn't go Oh, sorry. Go ahead. I was just gonna say we have a a question from Jack in the chat, 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? That's why we would do it. Yeah. I mean, in the end, I think

1:01:59 Why Import Whole of Lodash

1:02:11 Webpack is gonna strip a lot away that may not be needed even. I 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 modification and a whole bunch of other fancy stuff that I've seen the compiler talks from conferences, but I had never paid enough attention to understand it. Yeah. I believe you're right. Okay. I think one thing I wanted to point out is sharing functions as well. If you go to the policies folder again Mhmm. To

1:02:37 Sharing Functions

1:02:42 the to the source folder, sorry, with that contains these policies, you see this lip folder as well, right, on the one level higher. 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? So you have certain policies which apply to deployments. You may have other ones which apply to pods. Right? They have a totally different spec, but you may wanna check similar things. You may wanna prevent, you know, privilege escalation, for example, and that's part of the pod spec. But you also

1:03:21 wanna check it for deployments and stateful sets. And in Lib, you'll find a function which essentially can be shared and called from both of these policies, essentially. Where's the end containers or metadata? 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? We're essentially running something here on the pod spec, and this function expects the pod pod spec as an input. Right? Alright. Okay. And if you're now going to the policies again, so to your source to the source folder and then policies,

1:04:06 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? They may have different annotations, etcetera, but both of them wanna do that cap capabilities check. And then we can essentially if you go into validate ports, for example, and then in the actual TypeScript code, you'll see that we're running this validate container capabilities, and we're passing the pods back to it. Right? It's pretty straightforward. Yeah. I like that. Being able to extract

1:04:46 all the common functionality into shareable libraries to avoid duplicating code everywhere that you go. And just having simple functions like validate namespace and validate container images. Yeah, that makes a lot of sense. Very nice. I like that. Alright. Is there anything else from an example of repository you would like to show our audience before we finish up for today? I think that was a lot of content already. No. That that that's alright. We have we have covered a lot. A lot for hold on. Let me pop it back over to there we go. Yeah. There there there is

1:05:26 a lot here. I mean, I think just exploring the capabilities from the validating and mutating aspect and be 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 is 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

1:05:32 Summary and Future Potential

1:05:54 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 like you who, you know, are very familiar with JavaScript and TypeScript and and wanna 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

1:06:24 reason and are looking for something where the policies are are easier to read. And, you know, the thing that I wanna 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, I really recommend taking a look at at jsPolicy. Yeah. You're 100% right. Like, people need to be adding policies to their cluster, especially with policy could be policies being deprecated. There's a whole bunch of malicious things there that just need to be stamped out, and

1:07:02 jsPolicy is a nice way of doing that. I really like that capability of working with Versus 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. That's really funny. Sorry. How'd you go? No. I I was just gonna say I I hadn't even thought about that. I I don't have access to Copilot yet, so I haven't I haven't I've gotta be honest. I'm so amazed by it. And I know there's a there's a whole bunch of ethical debates

1:07:30 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 am trying to do that thing. So maybe in time, as more people adopt JS policy and are writing their policies, we'll find that a lot of that Copilot magic is gonna work there. And pod security policies be I can see that being distributed as an NPM package, and I'm leading on top of that more and

1:07:57 more best practices that are really hard to find in the Kubernetes ecosystems. And I think with JS policy, Loft 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. Any final words before I let you both get back to your day? Just thank you so much for for another invitation. That that that's really great that we, you know, are talking about a second project just, like, I think, like, a month later or so or two months later. It was a lot of fun talking about

1:08:18 Closing Remarks

1:08:32 vCluster, and it looks like jsPolicy went smooth regarding the demo as well. Like to see that I was since you mentioned at 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 vCluster is something that had been part of our commercial prod product before we open sourced it. Right? And so people have been kicking the tires on that for for quite a while, but but jsPolicy is is quite a bit newer. But it it's always fun to to see your take on these rules, David. Like, you

1:09:05 know, you always come up with some things that 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. It's just really I'm 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 gonna have to go and kick a tires with us 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 it's gonna be wonderful for for what I need.

1:09:32 Unfortunately for you too know how it goes. Unfortunately for you too, that you've now come on and demoed two projects that I really, really like. So, like, the third one's gonna have to be phenomenal. I don't know why you've got cooking in the kitchen, but it's gonna have to be good. So no pressure. I think we I think we've maybe taken a break from launching new open source tools for a little bit. We we'll see. Would yeah. Because you're already tackling difficult problems like policy and multitenant. Like, anytime I now have a difficult problem, I'm just

1:10:00 gonna have to be like, hey. Here's the thing. Please go run with it. So we'll see. Alright. 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. Bye.