Ballroom A Sunday Mar. 08 - SCaLE 23x

This talk presents Nathan Moore discussing the AOS Network, an open-source project aimed at solving global coordination challenges in container deployment. The AOS Network allows users to deploy containers across decentralized platforms, utilizing a governance structure similar to decentralized autonomous organizations (DAOs). The speaker emphasizes the network's middleware capabilities, enabling users to select from various providers based on features and pricing. The session highlights trustlessness in transactions, cost-saving measures through a decentralized compute marketplace, and the use of the Cosmos SDK for enhanced functionalities. Nathan concludes by addressing the importance of participation from the community in shaping the future of the AOS Network, indicating both its growth potential and current challenges.

check check. Hey, hey, check. Check. Hey, hey, hey. Check. Check. Check. >> Check. Check. Test test test. >> Okay, sounds good. our presenter Nathan Moore is going to explain to us about a cache network. So let's welcome Nathan to the stage. Thank you. >> Thank you everyone. I appreciate it. Um I know we have a little bit of a small crowd today. That's actually a good thing

uh in my opinion because it means if there are any questions we'll actually be able to get to them and we'll be able to talk about them. Uh this isn't going to take too long again smaller crowd and I would rather optimize for everyone here rather than try to speak to a general audience which didn't show up. Um so let me start out with uh this particular

project. This is Oh yeah, I should start with the usual disclaimer. Every corporation makes you put something like this in. Uh Penny Mac is no exception. So this is they're not related at all to this. This is really me doing it on my own time because I find the project really interesting. I find it a lot of fun and it just matches really well with the way

that I think about the world. Um so aos network is named uh after comes from the Sanskrit of the basis and essence of all things in the material world. The first elemental created. So this hopefully gives a little flavor as to what the original dev team was going after with this project that it should be some sort of base layer. It should be the ether. It should

be the air that we're all breathing together. It should be something that allows everything to come together. Um because that's what's the first element created. This the basis on which we're going to build things. Whoops. Now, Aasha itself is a Apache licensed 2.0 open source project. uh there it comes out of the crypto world and as a result it uses a governance structure very similar to a

DAO a decentralized autonomous organization where the decisions are made by the token holders in a weighted voting system. So the number of Akos tokens you have determines the weight of your opinion and uh how the community ultimately evolves. So, it's very much a community-driven product and the uh there's a very very active discord roughly 24,000 people in it right now. So, it has a very large number

of users, very large number of active developers. The a lot of uh commits into its repo. Uh like most of these things, there was an original creator who came up with the original idea and did the original work. This was provided by Overclock Labs and they remain, of course, the largest contributor to the project. No horrible surprise that's true of most of these kinds of projects. Uh

what AOS is really trying to do is it's trying to solve a very very big global coordination problem. It's really not meant for a local container problem. It assumes that that's solved. It assumes that it can take advantage of Kubernetes everywhere. But now you have a problem of federating the things together because you can have different clusters in different places and different providers and everyone's going to

run their own cluster. Now you have a coordination issue. If I want to run a container, I'm the guy who wants to run a container. Where do I want it actually run? Who who's actually going to host it for me in this federated environment? So, it looks something vaguely like this. Uh, yes, I I absolutely used Google's nano banana to create the slide and so it's a

little bit in the busy side, but uh it it does demonstrate what I'm talking about, which is that we have someone who wants to run a container. They need some sort of middleware layer which allows them to actually go and deploy it somewhere but not just in one location. You can pick and choose which location you want to be in. So you can have multiple providers. Why

have multiple providers? Because different providers are going to charge different prices. They're going to have a different set of use cases that they like to support. They're going to have a different set of features. And you can and should be able to pick and choose amongst them as to which one is going to do the best job for you. So to make this happen there's this entire

decentralized compute marketplace. So the way that Akos chose to solve this problem was not in a centralized manner. There is no one authority which says okay you go here you go there you go there. Instead it's a fully decentralized solution which means we get a lot of the traditional benefits of decentralization and we'll see some of that shown up in just a moment where we care about

things like trustlessness. We care about things like encryption everywhere in flight, at rest, you name it. And we care very very deeply about the ability to uh sign things so that we can trace back who did what. So we'll have a permanent ledger so we know exactly who signed up for what service at what point, what did they pay, and what all these other commitments are represented.

So those go into a permanent ledger. So it really takes advantage of a lot of the mechanics that a blockchain has to offer. And that's why it says in the middle it's this compute marketplace because how is it that the person who wants to run a container mediates with this person who wants to host that container? That's what this project is here to solve. All right. So

I mentioned a little while ago that or just a moment ago about how we require trustlessness. Uh because we have to be sure that if I'm going to have a decentralized environment like this, how do I know that the provider is actually running the container that I want them to run? How do I know that the compute that I intend to have accomplished is actually being accomplished?

And this is one of the reasons why we have to have a trustless environment. The moment you have made that commitment, that commitment now needs to be cryptographically secured such that the provider has to follow through on the initial commitment. And this is one of the reasons why the um this is a natural natural state sitting on top of a blockchain where you have a permanent record

to enforce this which is auditable and you can go back and validate and verify that what you thought was going to happen is indeed what actually happened. So the other thing that I wanted to bring up about the blockchain in particular is its permissionless nature. The idea here in order to have a marketplace is anybody can enter the market on either side. So we should not be

discriminating against who is allowed to run something. It could be anyone and it could be any number of anyone's. And at the same time we don't want to discriminate on the provider side. Anyone should be able to participate with any class or quantity or number of equipment that they have. And this becomes really important because one of the things that this winds up solving is for how

is it that I can take advantage of otherwise obsolete equipment. How can I better take advantage of the current structure? If I have a even desktop class computer sitting around and running and I'm not using it 24/7 and I want to make it available at some particular point, why should it not be doing I'm paying the electricity for it either way. So why should it not be

doing something which is of use? In other words, it's trying to find these additional uh layers of abstraction that it can apply to take better advantage of the equipment that's out there as opposed to the equipment that we want to be out there. And there are a large number of practical cost-saving measures which wind up driving the cost to provide to host the stuff down and therefore

the cost to run the stuff down. And this is one of the secrets. This is why this becomes so incredibly interesting is because if we have this middleware layer which is between the providers as well as the people who want to actually the the the compute customers we we're not dependent upon a centralized solution like AWS for this. So the vision starts to pull out from the

chaotic world into the specific and that what are we trying to do here is we want to be able to run this in permissionless environment. I do not want AWS to tell me, hey, you violated my terms of service because I just don't like the way you look. That can't happen here. That's the point of a permissionless environment. So, some real quick marketing stats because these kind

of projects people always ask, well, who actually uses it and is there anybody who actually would use it or is this just some sort of niche hobby? And the uh global application container market is actually fairly big. there's like three and a half billion in revenue out there. So there actually a large number of people who are willing to pay just to run a container random container

somewhere. Uh it's growing rapidly 27% year-on-year which means that by 2035 they're going to expect about $39 billion worth of revenue for the space. Uh interestingly is the 75% versus 25% cloud versus on-prim. The vast majority of people who want to run a container want to run it in a cloud. They don't want to be the ones responsible for it. They don't want to self-host. they want

to run it in the cloud. And once again, you see how this fits together with what the um Akos vision is trying to allow you to do. Um couple more factoids about it. Yes, it was started in 2015. Uh Gregosuri and Adam uh although mainet didn't launch until 2020. This does use the Cosmos SDK. So that's the specific blockchain that it's sitting on. They they basically are

running their own blockchain just it's built on top of the Cosmos. uh they brought in GPU support in 2023 and this will be one of the things we're going to see through here. My uh example uh is going to be uh about deploying openclaw on top of aos and that means of course you need some sort of um AI solution backing that one of the ones you

can use is a ML. So you can actually use the AOS network itself. Go ahead, run a container on somebody's GPU somewhere out in the cloud and it's going to talk to your openclaw instance also getting run on another container somewhere else across the distributed network and they can all talk to each other and it all works. Uh and yes, there's a very active Discord about 24,000

people in it. Uh so it's it's it's it's a lively lively project. It's alive and well. Has this taken the world by storm? Well, no. So if you look at the actual network summary of what the product is and the product is live, it works. We're going to see some examples of that. But when you start looking at okay, well fine, what's the total spent USD? We

just talked about a three and a half billion dollar market. Well, Accasha is responsible for maybe $5 million of that. So not very much. So the this is both good news and bad news. This project is at its start. It's at its infancy. It's at the beginning. There's a lot of room to grow. uh and there's a lot of space here but it's very much also because

it's small there's an opportunity to jump in and actually make real substantive contributions to it and like I said it has a decentralized governance model so it listens to its community in a way that most projects don't because the community votes on what is going to happen and what isn't and so all it takes is some level of ownership of AKT tokens and congratulations you get to

vote vote and you get to determine very directly with real power what is going to happen with the project and this is one of the things that makes it a little bit different. Okay. So, when we look at like resources lease, there's 500 active leases currently on the platform. It's generating uh uh $2,000 per uh per day, which isn't very much. Like I said, this is a

relatively small. But if you look at network capacity, network capacity, what does it say? It says that we have uh 8,200 virtual CPUs across all the various clusters that support it. There are 53 active providers. So, there are 53 clusters that you can deploy your uh container to. And that uh this these clusters cumulatively uh give you over almost 53 terabytes worth of memory and uh half

a pabyte of storage. Okay. So how does this actually orchestrate everything together? How does it all come together? How does this marketplace actually work? Again, we are in a blockchain environment to handle our distribution. This is all decentralized. And so I'm going to start off on the lefth hand side with the bit engine. So the bid engine works by as a reverse auction. What's a reverse auction?

A reverse auction is where in a normal auction you say uh you have one product which comes up for sale. Everybody bids. I'll give you $5. I'll give you $6. I'll give you $7. The highest price takes it. It ends. The gavvel comes down. The auction is over. Well, the reverse auction is the reverse of that. Instead, someone comes up and says, "Hey, I want to buy

one project." In this case, I want someone to host my container. All the providers now say, "Oh, I'll do it for $5. I'll do it for $4.50. I'll do it for $3." And then the person who wants to run their container picks from all the providers to say, "Hey, that's the one that I want." And for whatever reason, could be feature, could be price, could be any

number of things. and then you provision out to their service and you proceed on. But the reverse auction is key. Now in a blockchain context, how does this how do we actually make this happen? And this comes down to the nature of a uh that when you have the the word that Akos likes for the client is tenant because they think it's like a tenant. You're renting

somebody's server and so therefore you are a tenant on the server. So they're using the word tenant instead of client. So uh you have to broadcast out the request. How does this work? This means I take my wallet. My wallet consists of a public private key pair. Of course, you only make the public part available. And your wallet address is the public part of that public private

key pair, which means you can sign a transaction and verify that it was you because you sign it with your public key. So what do you do? You need to broadcast out your request, which means you're signing a transaction. Hey, I want someone to uh host my container. Here are my requirements list. You broadcast that out. You make the commitment onto the blockchain. The blockchain, what does

it do? Well, it gossip amongst all of the validator nodes and broadcasts out your request to every single one of the validator nodes. The validator nodes see this. Oh, I see this request. At the end of every block cycle time, a new block has to get created. What does that block created contain? Well, it contains your request. So, your request is permanent. It's written in. can't be

changed. It is absolutely verifiable. You are who you say you are because we know what the wallet address is. We have your public key that you've made this particular promise and that really was you and that's what's written down to the blockchain. This is permanent. Now, what do the providers do? Providers read in from this block and they're scanning. So, they pull every single new block and

they say, "Hey, a new request has come in from a tenant. What should I do about this?" And then the providers have to say, "Well, yes, I can meet the requirements. I have a GPU or whatever other feature was necessary from the uh that the tenant requested and now I can actually go ahead and place a bid. Well, I'm willing to do this for $5 a month.

I'm willing to do this for $10 a month. And then that gets sent back. How does it get sent back? That's another transaction of the So, you just write that commit. Once again, we know who they are because we've got the public address of the wallet. Everybody has their own unique wallet address. So when you do the uh response to the bid, you're putting your own you're

signing it with your own key. Therefore, we know the provider is who the provider says that they are. That they're not someone fake. They're not someone who's cheating. They're not someone in the middle who's going to say, "Sure, sure, sure. I'm going to run your container then not actually do it." It really is the person on the opposite side. Fine. So, you make the commitment and then

all of a sudden that get written down to the blockchain. What happens? The blockchain goes gossips with all the other validator nodes. Everything gets written down. the block gets uh written and then all of a sudden the tenant now can select the bid because all those bids just showed up in the next block. So all you have to do is read the next block. Oh, here are

the responses to these. I know who I am because once again I have that public address. Everything was appropriately signed. I just work backwards. Now I know how to match up what the uh tenant is going to be with the providers. I make my selection. Execution starts. I submit my uh SDL script over and everything spins up and it all just magically works. But it lines on

top of a blockchain semantics very very well and it works very very well for a very large distributed environment which dynamically allows people to add or remove themselves from it on either Uh specifically yes I was talking just a moment ago a message create deployment message create bid message create lease and these are our our primitives basically the properties that we need in order to actually make

this whole thing happen. And this is how we just match between the buyer and this wire. Uh I should mention here that I uh we did talk a moment ago how this is built off the Cosmos SDK, but it's set with a six-second block time, which means that the time it's going to take elaps between when I want to get a provider and when I can actually

get my container provisioned is 12 seconds. Two blocks. First one I have to write down my I have to commit my first transaction. I want this. the second one things come back and uh biders come back I get to select it and move on. So 12 seconds the nice thing about Cosmos I'll just sort of throw this in in the background is uh Cosmos because it implements

Tenderment. Tenderment is the consensus protocol after it goes and gossips hey this guy wants to make a commitment. How do you know that the block that you've chosen is hit finality? It's permanent. It's not going to change. Uh that's referred to as finality and tenement offers of instant finality. Another quick side note, um we can go further if there's interest, is how it implements a Byzantine fault

tolerance, which means it can tolerate instead of being susceptible to a 51% attack, it's susceptible to a 67% attack. So it does improve a little bit on the quality and this is one of the uh fun things that goes in and it is a proof ofstake network. Uh the providers themselves can run validator nodes because we talked about that when you gossip, it's the validator nodes which

are gossiping to each other. So you can absolutely run one as well and participate in keeping the network alive. And like any um blockchain, you are rewarded if you get if you have won the privilege of mining the next block, then you are paid out some level of tokens. So there is a very positive reason to run a validator node. You are paid to do that. And

that fee ultimately comes from the value of the token that everyone has to pay in order to pay their rent so they can become a tenant on somebody's container host. all fits together. It all fits together. This is why it's so fun because you can see the pieces of the puzzle, how they fit together. You can see how the concepts of what we're trying to accomplish with

the container world lie on top of the blockchain world. It all fits together. This is why I like the project. It's a lot of fun. So, yes, uh the formal timeline, we talked a little bit about this how this works where uh the commitment goes through with the timeline and again within 12 seconds you finally hit to the fine completed contract. um blockchains of course even Cosmos

will also implement smart contracts and so you can actually have a formal technically I guess it is a signed contract because once again it is signed with your encryption key again I want to come back to the theme of everyone can participate there really isn't a gatekeeper here and this is super important when we start talking about when you are a provider, what resources do you have?

And it winds up there's a very very wide variety of providers. Some guys are Yes, absolutely. They're running their desktop in their basement because, you know, it was on anyway, so you may as well do something useful with it. All the way up through guys running this stuff inside of actual data centers and uh various levels of professionalism. And so things like uptime become one of the

components that you can compete on when you're talking with uh when you're competing against other providers for the privilege of getting to host that Another thing that lines up really well with the blockchain world, rent is due every single block. So every single every six seconds you have to pay to keep your container running. Now bear in mind this is a tiny fraction of a penny like

0.004 cents like on that ballpark. So it's not like you have to pay $100 every six seconds. You're paying a tiny fraction of a penny. And so if you multiply that by the number of seconds in a month, you're going to get to a couple dollars a month, $5 a month, $6 a month, whatever, depending upon what the provider is willing to do. It is a market.

The price will shift up and down and the feature set will shift up and down based on what it is you're trying Uh but this does mean that settlement occurs on every block. So if you go to go to AWS and say, "Hey, host my container." Fine. And yes, they have services to do this of varying complexity and of varying price points. And you can use their

centralized service if you like. Um, and they will bill you on a monthly basis, which means they can cut you off and hand you the bill and congratulations, you you you're prepaying for the next month. So, if you've ever played with uh um especially some of the dynamic uh virtualization aspects of AWS, you know what I'm talking about where you say, "Okay, this gets saturated. So, spin

up a new instance, that gets saturated, spin up another one, and then all of a sudden your monthly fill comes out to be, you know, two times, three times, four times what you thought it was going to be." And so, that makes planning a little bit difficult. Whereas here, 6 seconds, that's all it takes. And you can spin up, spin down. Um but it leaves you with

a much more flexible billing model. And as mentioned, cancelling is trivial because that's just a commitment to the blockchain. Within six seconds, you're All right. So, the next thing in here is the actual cluster service, the resource management. And this is what I suspect this room is going to be a little more interested in than the other aspects. because what that you cannot prevent anyone from participating

as a provider. That means your provider can have there there are some minimum requirement levels. So you might be getting those or you might be getting something some substantially better. Again, you get to as part of the negotiation process, you're picking and choosing the provider based on what is that they can provide. And so this is what they have an incent now has incentive to make sure

you are running on something better rather than worse. At the other hand, there's such a wide variety of price points that they can afford to price down. So the use of AOS winds up being substantially cheaper than pretty much anybody else because you're reusing otherwise unusable equipment in some cases, but the available availability and the option is there to move up the hardware scale if that's what

you want and you're willing to pay for it. So there's a wide wide wide variety of uh availability here. So, one of the things that uh I did for this is I looked at the minimum requirements uh you know 8 core CPU, 16 gigs of memory and I went ahead and deployed it on a server. I got my son's old gaming PC out and that had sure

enough eight cores Intel i7700 if I remember right. Uh had 16 gigs of memory. I I had a NVME SSD, so I used that, but otherwise I was able to go ahead and deploy it and take advantage of it even though this was running off of my home internet connection on a DHCP service. So I was able to set up just dynamic DNS, able to point my

CNAME over from the permanent name that I was giving a kosh over to my dynamic DNS name and have everything continue working. And so even if the uh public IP changes whatever it's all going to percolate through an update and of course least IPs static IPs are something you can pay for with the professional hosters and that becomes one of the things if you're willing to pay

for it is absolutely available. Um so they give multiple ways to deploy the thing. You can use nansible playbook uh you can use cube spray uh you know they have a provider console which tries to do the bulk of the work for you. The developers have spent a lot of time trying to make sure that this is easy to deploy. You do not need to be a

although it helps to be an expert in Kubernetes in order to do this. So basically when I was doing this myself what am I doing? I'm just running the Ansible playbook. I'm letting it install K3S and I'm just kind of off to the races. It handles the bulk of this stuff for me. And sure, sure. I have some games to play with my network because obviously I

want this computer isolated from the rest of the computers on the network. So fine, you can just play no shortage of games to do that. And this is all internal networking. You can get as complex and complicated as you like or as simple as you prefer to be depending upon what your own risk tolerance is and what your uh level of expertise is. Uh yeah, but it's

basically currently built off of Ubuntu 24 long-term support. And so nothing surprising there. Uh the manifest service, the manifest service, uh we have an issue because once we've gone ahead, we've matched up buyer and seller. I want to go run this container. Great. We've come to a price. We have an agreement. I've selected the right one. Now I have to say what container do I want to

run and what specifically do I want about to do about that? And this is what the manifest for. So you have a manifest file which is what actually gets sent out to the provider telling the provider what it is the provider needs to do. And so Akos to make this happen to find their own stack definition language SDL. Uh it's just a YAML based declarative language. There's

nothing ex exotic about it. If you used YAML before, you recognize exactly how it's laid out. And now all you have to do is figure out what are the specific properties you're going to embed within this YAML file. And that's that's the only uh funky thing. But what are you really doing with it is you want the configuration. Do I need a static IP? Can I share

a domain name? What is it that I I want specifically for it? Uh resource requirements. So I have to tell it, well, yes, I do want a GPU. And not just any GPU. I want a very high. I want a H200. I I don't want a consumer level GPU for instance and various other deployment parameters. Okay, what reg container registry am I talking to? Where am I

getting to it? So it's it's basically similar to a docker compose but there is a formal language and they have a formal documentation with it. So the specific example I mentioned uh deploying openclaw so they have a nice standard one. Uh you'll notice that the reason why I copied and pasted this part of the configuration file is there's that setup password equals change me to strong password.

So that's always it is a configuration file and so you have the usual issues with configuration files where you don't want to embed your passwords in it and you don't want to commit passwords and you want the usual set of security uh issues around that. We'll talk about that a little bit more shortly but that's why I brought this particular example up. Okay, so we have the

manifest servers. We know we've got our people do providing the service and we know this is going to be run inside of Kubernetes but Kubernetes has a set of operators in order to extend its functionality and so AOS takes advantage of that and there are multiple operators that get deployed to it. uh one of which is an inventory operator because you have to report back to the

service what is actually there because it's pretty important if you're promising an end user no really I have an 8 core CPU you need that verification and validation coming back and so there's an operator to enforce that uh it also checks on the status of the GPU so if you tell it hey I've got an RTX 4090 congratulations you can now match that up against expected workloads

or whatever your GPU winds up being and so it validates and verifies and pushes that inventory out. Uh there's also an IP operator. So we talked a minute ago about how by default uh the minimum environment lets you run in using dynamic DNS. So you can be in a non-static environment and still have this work because DNS is going to handle any IP change for you. So

the worst case that happens is you have your TTL and your DNS record. That that's that's the worst that's going to happen. Once that expires, it goes to the new one and off you go. So just set a really short TTL and you're not too shabby and you can actually make it work. However, if you want a static IP, you don't want to be in this particular

world and there are reasons to do that. You need an operator to make that happen and that's what the IP operator is ultimately about. Uh you also have a hostname operator that a lot of this stuff as you full well know is especially if you're using something like an ingress controller then all of a sudden you it matters very much. You're going to steer traffic by what

the incoming inbound host name is. And so you need to be able to set that and do uh custom hostname assignments and the like. So you need an operator for that and that is provided. All right. So that's sort of the overall architecture. This is sort of how things fit together. We have an idea of what the stack definition language is like. We have an idea of

what the manifest file. We have an idea of how you go about requesting a container. We have a idea about how you would go about actually hosting the thing. So, let's go ahead and play a little bit more with some of the um specialized workloads, some of the stuff that comes out inside of SDL. What does SDL ultimately allow you to do? Uh, one of the issues

is that by default, a lot of your storage is ephemeral. So, if you restart your container, too bad, too sad, it's all wiped out. You have to go get a fresh one. This, of course, if the provider supports it, you can uh supplement with a persistent storage. So there are options to do this if you as the provider have chosen to offer this up and then of

course it becomes part of the manifest and this is one of the things that you report back your inventory operator pushes that back out to the AOS network so everybody knows no really I have uh per persistent storage and I can deploy that. So there's some internal stuff because the the project is old enough now that it's gone through a couple generations of storage. Hence you'll see

this beta 1, beta 2, beta 3 nonsense. But really all it is is referring to as new generations of storage technology come out and they are faster. And then you can specify which one it is. And now you can vary the price and vary your feature output when you are the provider making an offer and you as the customer can pick and choose which one is most

important to you if you need it. Uh we talked a little about shared IPs. One of the fun things about shared IPs is that you can um if you're willing to use custom IP leases. You're willing to pay for custom that you're not just getting the static IP, but ultimately you're getting the ability to control port mapping. So now you can send whatever arbitrary port you like

and map out whatever arbitrary port you like. And that is once again supported here. So you can specify out that if you have a say a non-HCP based service, not a problem. you can go ahead and let the network forward that as appropriate. Uh not everybody has a GPU that they are willing to output. Some people do, some people don't and uh depending upon what the customer

ultimately wants. Of course, the uh provider can provide and so you can match things. There are guys running on the Kosh network who are running H200s. I don't think they've moved on to I don't think anyone has any of the black hole stuff yet, but I'm sure that's coming down the line. So, you have various points and in your SDL you can actually specify which class of

GPU hardware you want to run on and that way you can specify what model you particularly want and it tells you what the specs are and what you can what sort of performance you expect out of it. Um yeah, the container registries obviously any Docker compatible container registry is supported including if you want to run your own by all means run a private container registry or use

any of the big public ones. It is up to you. Uh and this just gets specified inside of the SDL The last thing I really wanted to talk about this is one of the key questions is this is one of the potential weak spots and this is one of the things where where I'm not 100% on board with the rest of the developers on this which is

that right now yes you do need to use a secret manager and you can use pretty much whatever you like the AWS secrets manager you name it. Uh, obviously support for that is in there because you're really just having to pass in what your appropriate uh um token is in order to be able to access it. So you put this inside of your SDL and that way

you can put it in. But then you have this sort of recursive issue. I would really really like environmental variables get set inside of SDL. So within your SDL file, you actually specify, okay, when you this container comes up, this use this environmental variable, use this for this, use that one for that. And if you're doing things like trying to put secrets in as an environmental variable,

obviously it will work. But this is potentially a problem because if you have your uh SDL file versioned, congratulations. You're now committing your secrets into your repo. Very very bad practice. And this is why I'm not pleased about this, but I I I agree with the point that you really can't prevent people from doing it if they that's ultimately what they're choosing to do. You have to

acknowledge that the person writing the SDL script has has a lot of decisions to make on their own. But I would absolutely urge everyone take advantage of the secret management tools and you'll be you'll be a lot happier. Uh but like I said, this is u one of those things I'm I'm um one of the few places where I disagree with the direction the project has taken.

Okay. Then if you want actual shell access, so great. I've gone ahead. I've deployed my container. I actually want to be able to go uh run something on it. You know, cube cuddle gives you all kinds of ways of executing internal commands and executing internal things. So, either you've put some sort of switch inside of your code somewhere that say, okay, if you get hit with this

particular thing, return the state variable or or what have you. Uh meaning even if you want to get to the point where what you want to do is run bash, you can still do that. It's a little bit funky here. So the specific way it's implemented, you have to know what your wallet address is because now all of a sudden you actually have to go into the

transaction logs in order to be able to track down specifically where your container is running and specifically how to get to it. And again, all these mappings are done within the blockchain itself. Going back to that and so that's why there's this deployment sequence number. So that's one thing that gets written down. This is why you have all these prerequisites in order to do that because you

actually have to be able to trace your way backwards through all the steps in order to get to the actual container itself. But you can. It just takes a little bit of work. All right. So, we're going to go through uh one of the complaints about the project in the past and this is a relatively new feature just within the last year is well the the project

was built with DeFi in mind. It's meant as a decentralized protocol. So, it's very much built using blockchain semantics and the way that blockchains work, but not everybody wants to do that. There are people out there who are using Amazon because it is Amazon and all you do is give them a credit card and off you go and you're off to the races. So, the question was,

is it possible to implement a similar use case for the Akos project? And this is what just shipped last year where it is possible uh you can sign up for them, you can pay with the credit card. Well, what's going on behind the scenes? What's going on behind the scenes is yes, you are paying into a uh money gets swapped out of US dollars into the AKT

token, which is what the underlying blockchain is expecting to get paid in. So, that goes on behind the scenes. In front of the scenes, yes, all you've done is you've seen a transaction to your credit card for 20 bucks, 50 bucks, whatever it was that you agreed to. and then all of a sudden from your perspective you're you can treat it just like you would treat Amazon

or Latitude or any of these other hosting providers who are doing functionally the same thing. Uh part of this the uh dev team decided to include a bunch of free credits so you're welcome to try those. There's a couple downsides to these. Yes, they do give you a 100 bucks. The downside is they automatically halt your containers after 24 hours unless you convert to being an actual

paid customer. But the if you have AKT tokens, you can simply switch over and use those directly. And anything you start that's getting paid out of your AKT tokens, of course, runs permanently until you've chosen to stop So, fair warning about that. So, this is really trivial. This is standard. You set up, click the start trial button, uh console.acos.network. Easy. Once again, the focus from the dev's

perspective was to make this as easy as possible to use. Once again, because they're really trying to push adoption. It's hit that point where enough people use it, it's a real service, but not enough people have used it that it is a common service. So that's why I showed the figures from earlier talking about what the actual size of the size of the the AOS universe was

like. And right now, it's very All right, hence the need for the no crypto wallet. Once you go ahead and accept your free trial, great. You get the very default uh user interface here where they tell you what your total cost is, how many deployments have you got, uh what your available balance is. There's links to documentation and if you look in the lefth hand column, you'll

see templates and SDL builder. And so we talked about that SDL is how we're building the manifest. So we can have custom manifest and we can write whatever it is that we like. And when you write a manifest, that then becomes a template for what you're trying to do. And this is why we're going to go through and demonstrate what the specific template is for um openclaw.

Great. So I've gone through I went into my template selected the open claw template and what happens is all of a sudden if you look on the lefth hand side you have to confirm that are you sure you want to do this and if you look at that I want to point out the um the the top line here because embedded within that top line is a

bunch of what looks like really random numbers but what it's actually doing is it's showing off your wallet address and this is how you can look backwards. Once you know what your wallet address is, you can look backwards and validate and verify, was this really me? And all of a sudden, you know that it is. And this is why it's important to know what the underlying concept

is. So this way it doesn't show up and look like random number. At any rate, I go here uh confirm my deployment creation and then when I click continue, the right hand side shows up and all of a sudden we talked about the reverse auction. What happens? Everybody shows up who uh wants to go ahead and host this container. If you look at the top line uh

above the dollar figures, you see what is it that I'm requesting? Well, I need three CPUs, uh six gigs of memory and 16 gigs worth of disk space in order to run Open Claw. And so all the providers said yes, I can do that. They've gone ahead and placed a bid. Uh this $6.77 per month comes from a uh provider, what is it? Europlots.com. If you look

up under region, it says HR. It turns out that's the country code of the Czech Republic. I did not know. I had to look that up. But if you don't want to host out of the Czech Republic, you could also host in the uh in Texas. That's the next guy down. And if you don't want to host in Texas, you can host in Michigan. And there are,

of course, more providers here. There's well over 50 or 60 active on the platform. I just clipped out the top three just for space reasons. So you pick and choose who you want. You go ahead to success. gives you a little bit of details about what happened and what the provision cycle actually looks like. And so it tells you that you were able to uh successfully do

this. You have want to look at the top because I talked about how not just cost but it says time left. That time left is driven by the fact that I have a $5 balance on this account. I chose to only give this one $5. $6.77 per month. So five six of the way through the month, which is 23 days is when this lease is going to

expire. And that's hence the time left calculation. And it gave me my sequence number. So I know the sequence number where in the blockchain it was. I know the transaction within the blockchain that that commit occurred. So if I need to look backwards, I can find it. And it gives me the provisioning. So from the server side, uh, OpenClaw had no problem. It was able to create

a pod. It was able to um, deploy itself, bring itself up, waiting for a volume to be created. Then it creates it. It starts it. um this guy's uh provider is having a little bit of difficulty because he says zero out of five nodes are available but then it wound up working anyway. So clearly one of the pods was just busy and it came back and finally

it tells me that ingress has been scheduled and uh it's been configured. Let's go to the next page if it will let me. There we go. So after that I've selected the guy I want to host it. I just saw that it the thing came up correctly and then I get to this details page. So on the lefth hand side is we have details once again it

gives the uh monetary details. It tells me specific uh features what it's doing what it's providing and at the very bottom it says URI. So that's the UR the whole thing deployed at and I talked about this earlier about how this is ultimately getting controlled by DNS. So I it gives me a very uh DNS-based URI. If you click on that URI that's why I included the

the bar at the very top. Look, there's our open call instance. So, the thing worked. It did what I asked it to do. It set it up. And remember, enter setup password. That's why I pointed out earlier when we looked to the SDL that it was actually set that to change to a stronger password. And that's the password you would inst uh use right over there to

continue uh setting up Okay. So, it is possible to use the thing without a crypto wallet, without a lot of DeFi knowledge. Uh I acknowledge that uh DeFi can be very intimidating. It can be very complicated. It can be very confusing. And there there's a lot to dislike about it. It has a genuinely a terrible terrible user experience. So that's why we spent the time first to

go look at the easy way of doing it. What's the harder way? Well, the good news is that if you are um familiar with a lot of the DeFi concepts, so bridging for instance, and the on-ramps on the and the off-ramps to get into the DeFi world, then this is straightforward. If you don't, we're going to take a minute or two and step through that. Great. So,

window on the left at the bottom, there's the switch to wallet payments, and it says, "Okay, well, great. Which wallet?" Uh, for this particular project, Kepler is a Cosmos native wallet. And so, we'll go ahead and use Kepler, and we'll put that together. And what we're trying to do with Kepler, so yes, it requests the connection and it passes it in. The issue with ke Kepler is

that first you have to go through the wallet creation process. What's the wallet creation process? This is where we determine what is that public and private key that you're going to use. Every address on the blockchain is your encryption key. Not your private of course, but the public one. and that in order to regenerate your account, you are given a set of specific code words which need

to be entered in order in recover your account. So if you forget your password, that is literally your only way of getting that back. And this is one of the challenges of DeFi. You have no central authority to call up. I forgot my password. Reset it for me. Does not exist. If you've forgotten your key codes, then that's the only way you can get it back. So

once you have your public address, then you actually have to fund it. And that is one of the very very big challenges in the DeFi world because to get tokens on the AOS network, Akos is running their own blockchain. It's different from everybody else's. Yes, it uses the same semantics as Cosmos because it's built off the Cosmos SDK. So, how do you get money into and out

of it? Is the first thing you have to do is you have to fund your wallet with the native coin of Cosmos because it's a Cosmos chain. But then we're going to have to bridge it over to the Akos blockchain because Akos runs a different blockchain, just same semantics because it's the same SDK. And in order to do that, you can take advantage of a DEX, a

decentralized exchange. So you fund your wallet, you go to like a centralized exchange, Coinbase for instance, you buy Cosmoscoin, which is Atom. You then have to go and bridge across from Atom over to uh the Akos blockchain. And in this particular case, I'm using Osmosis as a DEX, a decentralized exchange to do that. You don't have to use a DEX. There are other ways of doing this.

Um, but this is probably the easiest way to do it. And once you have bridged the things over, then you can swap Atom on the AOS blockchain for AKT token on the Akos blockchain. And now all of a sudden we have the appropriate coin that we can use to pay for the gas fees as well as pay for our utilization on top of the Akos blockchain. So

you can withdraw your AKT back from Osmosis because osmosis was just the dex dex. So you were just committing your tokens to there and you can pull them back when you're done. So this is why I say this is why the DeFi it's it's not a very good user experience unfortunately it's the DeFi world with the benefit of hindsight the point of the DeFi world is to

give you the primitives and the methods and the capability of refactoring the legacy financial system and do so in a way which it disintermediates all the people you would otherwise have to pay in order to make this stuff happen. And that's the problem is that in order to make that happen, we have all of the primitives, but now you have to be enough of a developer to

understand how you put those primitives together in order to make what you want to have happen actually happen. Is it worth it? I would argue yes. Uh, and this is something that we already talked about how a lot of these semantics get used internally. And so if you know what is going on, you can now trace stuff through and you can better understand what the system is

actually doing. And this is both a blessing and a curse. Okay, so I mentioned earlier that I went ahead took my son's old gaming computer and uh deployed it in order to become a provider and it was very straightforward, very very easy. You just install Ubuntu on it. Make sure you meet your minimum requirements and we already showed minimum requirements. In this particular case, I just installed

via anible playbook and I realized I had the console over there. So I had to take a picture of the display from the console as opposed to logging in remotely to it. So but once you do that, it's all very straightforward. You let it install K3S, everything comes up and uh you know, you're you're you're happy. At the end of the installation sequence, you wind up uh

picking and choosing how you want to price. And there's some various provided uh pricing scripts to allow you to do this. So this way this is what's monitoring the blockchain for new bits coming in and if you want to respond with customize your response to say yes I have this hardware I don't have that hardware I have this feature I don't have that feature and then this

is how you would do it you just write a little script to do it and then everything is automatic it happens on your behalf and you can come back and revisit this if you want to change prices if the model changes if your costs change what have you all right so that was a fair amount uh but I do want to this is a small groups. There's

I want to make sure there's time here for any kind of questions that we can either jump in. So we can talk blockchain semantics, we can talk a network, we can go back and look at how the uh whole process works, we can do high level, lowle, but it is absolutely open. Yes sir. Thank you. Um, sorry. In terms of security, how do you actually know that

these providers are going to provide the service that you're paying them to provide? >> Fantastic question. So, we know from the there's there's two ways to answer this. To answer this, I I actually have to first talk a little bit more about the context of the blockchain is giving us. And so, because we have the uh every transaction is cryptographically secured. We mentioned the public private key.

Everything gets signed. So, the provider has made that commitment. I am going to do this. There's already an operator running inside of their Kubernetes environment which has come back and is reporting here's my state. Here's what's running. So now you have a check. You have a way of validating and verifying that what it said it was going to do is what it's actually done. So you send

over the manifest file at the end of the sequence and then the provider is supposed to read the manifest file and then implement based off of that and then you have to check. >> Can I not just modify the operator to tell the system all is good? uh if you try to modify the operator, you violate a check sum and then that gets rejected by the system.

>> How like it's my hardware. Is this using like trusted computing or what's going on here? >> Uh it's not using trusted computing. What it's doing is it's taking its own uh check sum of the manifest file and reporting that back. So it has an existing operator to do that I think and please correct me if I'm wrong is what you're asking is what if I try

to short circuit that? Is that the question? Yeah, basically what if I just modify the entire system and make it report all as good here with the correct check sum and everything because they can just do >> Um, I guess that's one of those things which is technically possible but practically impossible where it becomes extraordinarily difficult to do that because now you're stuck violating all of the

contracts within the blockchain itself. So now you have to override well it's not that easy. It's um I disagree very firmly with that. So you you have to go through and uh because now you have to violate uh the transaction that you've signed and this is why I was going back to the sequence numbers because as you trace the sequence numbers out everything gets signed and so

therefore you have to know what the appropriate counterparty is signing. Uh and that is in my opinion the real answer to your question is that if you can violate that then there is possible for a way to have the provider potentially cheat. The other way it could potentially cheat is if you are able to control over twothirds of the validators on the network because the validators are

the ones that determine what the next block is. So in other words, I can override that address with a different address and I can put in a different commitment. But in order to get the rest of the network to agree on that, I would have to violate the Byzantine fault tolerance in order to get that. So that's why I mean it is technically possible, but it's practically

extraordinarily extraordinarily difficult. Okay, I have a couple of questions involving workloads. >> so um one of my questions is so we're talking about you know an experience where you're deploying containers that take a long time to comply deploy compared to like say deploying them in GKE or something um but are relatively longived because you're talking about billing by the month. So what sorts of workloads do people

run on the Akos network? >> Great question. Uh yeah, there there's a large number of um so the trivial answer is runners, but on top of that, there's a lot of guys who will use it for their own projects and there are a lot of guys who will use it for more serious projects. So it sounds like a little bit of a waffling answer because I'm trying

to remember off the top of my head who the top three projects are. Oops. so so there's a lot of guys any kind of asynchronous workload is a really really good choice. There are guys who are running uh using it as the backbone to the uh open claw for instance that was one of the things that I've played with it. Uh and there are a lot of

guys who have used it for really toy use cases like running Minecraft servers, anything which is um you you can take advantage of not just the low cost but also the fact that it's running pretty much anywhere. >> And then then my second question involving uh workloads actually follows up on that question, right? Because you mentioned >> and since OpenClaw was released, we've already seen some malicious

uses of it. >> Oh yes. And it feels like deploying OpenClaw to Akos network will make it even harder to figure out who owns a malicious OpenClaw instance than it would have been with, you know, regular hosted server. >> Yes. >> So what what tools exist, you know, if I represent an internet provider or law enforcement >> and I am trying to shut down somebody running a

malicious workload. >> Yes. So you have to trace back through the sequence numbers within the blockchain itself to know which wallet did what. But the thing is in order to use the service you still have to go through a uh you'll notice that let me go back and show the providers. Let's go back. Where was that providers list? There we go. You notice the provider has a

name. You have to register your name with the Oh, sorry. This shut off, didn't it? But you you have to register your name along when you sign up as a provider in order to be allowed on the system. So, because of the nature of the blockchain, you know what load is running where on which provider. Because you know the provider name, you already know how to work

your way backwards to, okay, I now have the name. that gives me the IP address, the um the host name, I have the website, I have the contact information of the person behind that particular provider. So I have a way to work my way backwards. Now the other half of your question is okay, what if I have a bad open call instance running on my system, I

am the provider and I've just been told, hey, you have a openclaw system which has just done something. What do I do? Well, it's running local. So I just use call uh coupube cuddle. I know exactly what the name of it is because that's given back to me because I was able to trace through the blockchain. I knew exactly which one it was. So, all I have

to do is match it up and I can even kill it by hand. Um, that's the fun thing with rent being due on every single block is that I can cut things off every six seconds. So, I can just say, "I'm sorry, your thing has been terminated and it's six seconds to do I guess my question is a followup in some ways to that as far as

um you wanted to kill an instance but it was as the provider. I should probably clarify that you wanted to kill the instance early uh before the tenants uh time was uh had yet to expire for whatever reason. Uh it could be a power outage. I know you would normally put a backup generator or something like that so it wouldn't lose power, but what are the the

norms as far as like it it being uh cut off too early even in the event of a malicious attack? >> Solid solid question. I think this hopefully helps answer the earlier question because or what it was hinting at because if you are the client, you have a fundamental issue that the host can cut off your service at any time for any reason. There is no guarantee

that it's going to be up 24/7 365. That's why they include the uptime number. see the uptime right over there and they're letting you know this provider is only up 99.99% of the time 98.08% 08% of the time and this is one of the things that you're ultimately bidding on on but this also goes back to the earlier question is well okay well what loads do you

want to run in this environment and clearly this is not going to be for something that I'm not going to run IBM.com on top of this this is it's or if I do it's going to be in some sort of exotic load balanced environment where I have multiple providers I can balance across sorry my timeout's a little too short and that is one of the challenges. I

I think that's one of the reasons why the product remains relatively small is because my personal use cases for this are are fun toy projects. I'm running open claw inside of here. I'm running Minecraft. I'm running uh simple toy stuff uh where what I really care about is a combination of lowcost and most of the time availability. I don't need 100% uptime. Um so this is actually

a solid solid point. I probably should have included this in the talk in that if what you want is the AWS 59 reliability then well that is what you're paying the premium for. So I guess I I probably should have brought that in. So from my perspective this is uh a toy which is trying to become a real world product but it's not quite there yet. It's

still just a little too small. It doesn't quite have everything locked down. You can see the vision but it's not fully I hope that helped. >> more questions? >> Okay. Well, with that, thank you very much, Nathaniel, of course, for introducing us to a new and very different project. >> Thanks everybody. >> Thank you. >> And we now have a one-hour break followed by the final sessions

in the program and then followed by the closing keynote. Um, so see you all in an hour. Check check check again. >> Yeah. Mic check. >> Yeah, sounds good. It takes a second. >> Mic check. Yeah, >> sounds good. Thank you. Good afternoon. Uh welcome to the final uh time slot of the cloud native track um at scale. Final time slot session time slot at scale. Um,

and in this final session, as you heard in the keynote this morning, there are more security and compliance requirements than ever. Um, and our speaker is going to show you a way to enforce compliance in a location you might not have expected. Um, so with that, let's welcome Sajal Nagam to the stage. Welcome. >> Yep. Thanks. Um, uh, good afternoon everyone. Uh, thanks for joining me. My

name is Sajil Nigum and I work as a as a senior application engineer with discover financial services which is now a division of capital one and today I'm going to talk about one of the open source tools that I have created. I named it as guardon which focuses on shifting kubernet compliance left with developer first guardrails. Now before I begin, I just wanted to make a disclaimer

that uh this is completely done as an open-source project by me and it has nothing to do or it does not represent the views of my company. With that uh let's begin. So talking about first the problem statement, right? What problem are we to trying to solve with this tool? So as you know like kubernetative misconfiguration uh slips through the reviews and it triggers some kind of

CI failures or in worst case it could be any kind of a production issues. So with that uh you know uh there are tools uh which are already available uh which are pretty good and we're not trying to compete with that or trying to replace that. But uh if you look at uh you know uh all these excellent policy escort tools uh like open policy agent or

uh you know kerno and there are many more right so despite of all these uh great tools the misconfiguration remains one of the dominant cause of uh failure uh in cloudnative systems. So the question is uh it's it's a question that really asked myself whether we need another policy engine uh to solve this problem but I think the right question to ask is you know are we

enforcing these policies at the right moment in the developer workflow so and that's where the guardon is and it's not a new policy engine uh but it's a system that explores a new enforcement point uh and that is running these policy code at the review time. So in a nutshell that is what the guardon is. It executes directly inside the pull request and entirely client side without

any CI and without any clusters without requiring you any credentials. Now let's take a look at what we already have like what existing tools uh are already existing and like at the earlier stage we have these actually I've divided that into three categories um like the first one is your ids which is pretty much the local stuff that you do on your local machine and that is

the earlier stage and that provides you a fast interactive feedback while editing the manifest. So that is a great way and uh all that for that you need to install those uh tools on your local system and then next we have the the you know uh the CLI uh command lines which is again on your local machine uh with the help of that you can have some

kind of a pre-commit hooks which will again validate your configurations or changes that you're pushing in. uh but all again that is also on your local machine and you might have to do some kind of an installation on your local machine or in case you're using some kind of a command line interface which connects to the cluster itself that would need some credentials as well right and

further downstream like you see there are uh the CI/CD integrated scanners uh which you know uh where the policies are evaluated and then uh it's actually after the code is pushed so the the CI scanners get triggered and they do the policy you and finally we have those admission controls which is uh pretty much a guardrail and you can call it as a as a authoritative governance

body which would uh reject or approve your uh workload onto the system onto the cluster. So you know see all these tools are valuable and as I said guardon does not intend to replace any of them. However, if you notice something important, uh each enforcement has some kind of a drawback, right? So, the earlier tools are pretty much fast, but they are private. That means like only

the developers who have installed would be able to see it, right? I mean the results uh when you run these and then the there are some late tools which are authoritative like the admission controller and the CI scanners, right? These tools are authoritative but they are too late. that means your code have already gone into um the pipeline and you have already pushed those changes. So at

that point uh those CI scanners and the admission control would give you the feedback right. So I will call it a little late uh in that process. So what I can say is the ids and the the CLI tools surface violations uh only to the author and reviewers don't see them right whereas the CI and admission controllers uh surfaces the violations to everyone but only the commit

but but uh only after the commits uh you see that in the pipeline or uh almost after the deployment has failed. So, so even the best-in-class tools uh you know enforces it remains fragmented across uh across time, context and visibility. So, that is why you know uh teams are often experiencing these policy enforcement uh as noisy you know late and frustrating. So even like when the rules

themselves are correct they exist technically but they don't exist at the time of review. So you know this observation leads to a simple but you know underexplored questions like what if we enforce these policies at the at the same moment the team already reviews and reason about the correctness of any configuration right so that brings me to the missing enforcement locus so now let's take a step

back and ask a very simple question right now where do teams actually decide whether a kubernetative uh changes is acceptable or not right it it doesn't happen on your local machine using ids. It doesn't uh doesn't uh have it in the CLI command line or maybe even of the CI pipelines, right? Because it is after the fact. So the pull request review is mandatory. It's auditable and

it's collaborative, right? It's already existing and and it's where the developers, platform engineers and security reviewers converge to reason about the correctness about correctness of any configuration. So you see that despite being the most uh important decision point in the SDLC phase the policy s code remains you know that enforcement is all almost entirely invisible at this stage at the review time. So review sees the YAML,

they see the difference, they see comments and then they see the the test results uh but you know they rarely see any kind of a uh structured policy feedback uh at the time at the time they're reviewing and in the context of what they're reviewing right so this creates a disconnect. uh the policies maybe you know technically ex technically exist and then but they are enforced either

privately that is on your local machine using the the the command line interface uh kind of a pre hook uh and the other part is if it is on the CI scanners or on the admission controllers that is almost too late so I see that the gap is not about the missing rules or uh the missing policies it's basically about missing visibility at the moment of decision

Right. And you know this observation motivates uh the central idea behind guardon. So what if the policy validations happens inside the code review interface itself at the at the same time the reviewers are already examining the change right. So that that that is going to make it interesting. Now uh looking at you know the policy the the place the policy enforcement uh right now exists across the

kubernet software de delivery life cycle. you know see at the time of uh at the time of the developers at development the developers are using the ID liners uh at the command uh time they use the CLI tools uh and then other pre-commit hooks as well right so at the integration time they have these CI/CD scanners running and the deploy time you have already have the admission

controller so each of these enforcements points exist for a reason and none of them should be removed and what Gardon adds on top of it is an explicitly review time enforcement tier which is between you can say between the the commit and the and the CI where the policies are evaluated in the same context as the human reviews. Now by servicing these policy feedbacks here uh we

reduces uh we reduce the chances that the violations survive uh any kind of a review simply because they are invinc invisible. Right? So this also explains why Gardon does not uh back any kind of a you know it does not block any uh commits or any kind of mergers. It just informs a decision rather than you know enforcing these. So the admission controller and CI pipelines still

provide these hard guarantees uh because all those are authoritative and they act as a guard. So they don't allow you to push any kind of a uh misconfiguration or compliance issues that that can be caught there. So in other words uh the guardon strengthens the governance uh without weakening existing enforcement guarantees. Now at this point uh you know uh some of you may be thinking about um

you know why a browser extension or is that really part of uh any SDLC phase and it's a it's a fair question to ask um and it's an important one. So the key insight is this basically the SDLC is defined uh by the decision point on and not where exactly the code is executed right so the pull request review is already formal it's it's mandatory and it's

auditable so that's part of the SDLC phase so anything that influences the merge decision at this stage you know that by definition is part of the so we already rely on these browser based uh delivery mechanism at the at the time of review and you know code owners reviewers uh they check the inline comments and security alerts all those already happen. So guardon is simply adding a

structured policy feedback feedback at the same context. So you see it's it's just about enforcing those policies at the at the So by running entirely client side uh guardon eliminates infrastructure dependencies um uh and avoids any kind of a uh CI scheduling delays and prevents policy drift caused by uh per development installations as I was explaining about any local installation that you have to do for uh

running these policies locally just in case and every reviewer sees this uh same violations which is very important because when you're evaluating uh against the same policy you should be able to see the same results and without requiring any kind of a step beyond just installing a a simple browser extension, right? For as an example, the local installations would need you to configure your uh uh all

those installations plus you might need some kind of a uh maybe some kind of a credentials to log into and connect to your cluster. So equally important this model actually preserves the privacy as well which is very important. uh you know the configuration data never leaves the developer machine and there are there is no need for any cluster uh credentials any kind of a secrets are involved

in this right and once you accept this review time uh enforcement as a valid SDLC phase uh the browser becomes a very natural place uh to implement it so I'm just talking about uh the basic idea uh by this time you might have already realized what I'm talking about but the guardon is built on a very simple idea and it's basically executing these policies directly inside the

pull request interface at the review time using the exact manifest the reviewers are reviewing. So that is the key and you can say that is the whole or the core idea of guardon. So when a you know pull request contains a kubernetative yaml uh guardon extracts that yaml file uh particularly that manifest file it sees the different that it validate that there are validates and then against

any kind of a schema it runs uh through the schema validation and then finally the policies are executed and all that surfaces those violations immediately. So this happens entirely the client side uh inside the reviews browser. So there is no uh cluster access, no CI pipelines, no external services and no credentials involved. So you will see that when I'm going to do the demo uh probably you'll

be able to realize like what I'm talking about. Um now again the important point uh the garden is not not trying to be any kind of another uh policy as code engine. Uh it does not invent any kind of a new policy engine or a language. It does not replace any of the existing tools, any admission controller or any kind of CI scanners. So instead it just

introduces a new enforcement phase at the review time right uh the the the that complements the existing tools. So you mean like all the organizations which are already existing these uh policy course tools it is going to leverage the same tools. So once you you know uh review the guardon through that uh lens maybe you know many design decisions such as being a browser based uh a

fully client side becomes necessary rather than accidental. Now uh I'll talk about a very on a very high level about the client side architecture that it has. So you know to make it a review time enforcement uh practical guardon is implemented as a fully client side a browser resident system and at high level uh it has you know three components uh in turn all all of them

running on the browser itself. So the first component is the content script uh uh and this component integrates directly in the pull request interface such as uh GitHub and GitLab and it's responsible for extracting the Kubernetes YAML files uh in the PR differences and including any kind of a multi-document manifest as well. The second one is the background service worker uh which is more of an orchestration

layer and it act as a coordination layer. It manages these active rules uh schemas all the validation I mean the orchestration part of those validations without relying on any external services. And finally the core uh is the core rules engine. I although I call it call it as a rules engine but it is not uh a kind of a another policy as code engine. It's basically uh

where the schema validations and the policy execution happens. So you know the the the design is more or less a deterministic design where schema aware and the side effects uh are it's not it does not have any kind of a side effects. So all these components runs locally and there is no server side execution as of today. So whatever I the version that I have released so

far it does not involve any kind of an external service or any kind of a external server setup. And I mean particularly this architecture was chosen deliberately to eliminate any common source of latency uh any any configuration drift or uh privacy concerns because you know uh any kind of a configuration leaving your system that could be a concern as well like for some of uh the uh

some of the industries. So because execution is local and isolated uh by the browser extension sandbox uh guardon can deliver consistent reproducible results with very low overhead. Now easy policy reuse. So I was already talking about uh some of the existing uh tools uh which we are trying to leverage. So you would see that in the demo that how I'm how I am actually leveraging uh particularly

verno and the open policy agent as is uh when uh and the important point is like at you know this is one of the design decisions which I imposed on guardon uh deliberately uh and it is it it's not it's it's because you know most of the organizations they don't want to do uh rewrite the policies right most of the mature kubernetes already have significant investment in

the policy as code uh particularly if you are using giver or if you're using uh open policy agents rego. So you don't want to uh you know rewrite these policies again just to have this uh a new tool introduced. So garden is designed to reuse those existing policy assets and uh completely rely on them. So at this at its core the garden supports uh right now as

I said like three policy sources right now. So first is the is the guardon native rules. So if you don't have those uh policy engines you can pretty much write your native rules on your own. And uh the second one is Kibono uh validation rules uh which is uh kind of a most mostly uh used by kubernetative uh native services. So it's a it's basically um it's

a lightweight and uh you know and then a lot of organizations have are using open policy agents uh for a lot of reasons. Uh so it right now with this version it supports both. So the point is that you know the the this means that organizations can take policy as uh as is like they they don't have to rewrite it and that I mean the policies that

run on your any kind of any any of your uh CI scanners or in your admission controllers the same policy would be executed at the review time in your pull request. So what we are doing is bringing those same policies which would give you the same results maybe after the fact the code has already been pushed into the pipeline it's gone that is going to bring those

all those reviews at the review time so that uh you can validate the correctness of those configurations. Now um this reuse model is also important uh for trust factor uh and the review time enforcement only works if team believe in the results and which is very important uh to establish that trust that if I am able to see a particular result of a validation then other person

should always also be able to see the same result for the same manifest right so that is the whole idea of establishing the trust and that's what you will see here uh why I'm calling it as a deterministic rule engine and it is very important that uh you see a a credible result right if if the different reviews see different violations or if the results change between

the runs right the system loses legitimacy and for that reason Gardon's core rule engine is explicitly designed to be deterministic so even you know the policy rules is is modeled as a pure predicate evaluated against a single kubernetative uh resource there's no there's no side effect or you know uh no ordering dependencies on there's no kind of an external dependency external context is needed. So before any

policy validation happens, each manifest is validated against a schema. Uh it could be either uh the kubernetative opi open schema or it could be uh you know custom resource definition. So that is uh pretty much common for any kubernetes specific things right. So all those can be loaded. So first step is that all uh the the yaml would be validated against uh the schemas and then finally

the the structured correctness. Once the uh the structured correctness is ensured then you go on to the semantic part of the checks. So you would see all that in the demo. Um and then the rules are evaluated independently and they cannot be you know they they can be executed in parallel uh using the brow browser web browser workers. I'm making some uh use of web web assembly

as well uh for uh taking care of the open policy agents and you know this design is uh it it actually guarantees uh you know uh that the given same the given the manifest and the same policy set guardon will always produce an identical result. So that is very important and that uh you know property matters not just from the performance perspective but also from the governance

and the reviewers so that they can trust Now another important point uh over here I wanted to uh make is that the develop developer time to remediation right. So latency is important but what really matters is something much more more uh you know much simpler is that how quickly a developer can actually fix a problem once they see it right so if you think uh about kubernetative

policies are the way they are enforced today u the difference becomes obvious right uh when the policy enforcement happens in CI the developer pushes changes wait for the pipeline to run then read the logs and figure out what went wrong. So and all that he has to repeat for every fix that he is doing. Right? So even what we see is like even the fixes is kind

of trivial. The workflow is not and waiting context switching and then you know rerunning these pipelines dominate the experience developer experience and that's where the garden is going to try to solve some of that problem in bringing these uh all these policies which happened after the fact at the time of review. So you see that the ID based llinters improve this by you know moving uh the

feedback earlier but they still operates in private context. So that we're not denying the fact that a lot of uh tools which run on your local machine would try to solve those problem but the point is they are all private right the developers sees the issues in the ID but the reviewers does not see that and that is very important because you know uh that means that

you know the review still requires a mental reconstruction and the reviewers will still have to uh to do that mental construction to get into the context whether this is going to again pass the policies whether developers already fixed something, right? So whereas with Gardon, you have that structured policy feedback right in your interface when you're reviewing it. So you don't have to do a mental reconstruction of

the problem, you already have that kind of feedback running in your local interface. So now when you compare this all this uh you know review time enforcement when the policy validation uh violations are you know visible directly in the pull request uh the next next to the exact lines being reviewed there's no waiting right uh you don't have to again wait for your CI pipelines and admission

control to r again and then give you the results back oh there is some kind of a problem now you have to redo again the whole cycle so fixing these problems becomes local immediate and you know the actions uh it is more actionable because you are able to see that review you are able to see that uh feedback at the review time so you'll directly fix that

problem before even going into the CI/CD pipeline or admission controller although you run it at the local as I said uh but it's not common for all the reviewers so the result should be consistent and should be sharable with everyone and this difference has nothing to do with um I'm Okay. So, you know, the difference had nothing to do with any kind of a typing speed, any

kind of a raw uh performance. It's it's all about eliminating that delay. Okay. So, we have those tools in place, but we are what we are trying to do is just uh surfacing that back into the Okay. So yes, Gardon does have some limitations as well as of now. Uh the version that I have released so far, it does have some limitations and I wanted to call

it out before we get into the demo part of it. So uh you know Gardon focuses intentionally on the validation part only validation only policies although you would see that uh the tools like no or open policy agents do a much more complex job. So right now the focus is not on uh you know uh having everything what these tools are already delivering right it's about uh

trying to capture the maximum what we can do on the local machine. So those capabilities require look you know those kind of complex uh things would require uh you know the clusters to be available those definitely the c cluster state becomes really important over there and the broader execution context are better suited for these kind of tools which are run already running as a as a guard

in the CI/CD or in the admission controllers. So uh the guardon also currently supports policies that can be reduced to to reduced to be deterministic uh resource local predicates. So that is that is where we are limiting uh guardon and it's highly dynamic policy that depends on you know the runtime state obviously those are complex scenarios so we're not trying to solve all those right now with

this tool and uh all this actually allows Gardon to be you know remains fast uh uh predictable and safe to execute entirely on the client side and that goal is not it's it's it's not a you know kind of a replicate of full admission controller As I said, uh it's basically to surface those majority of common misconfigurations early and when they are, you know, cheapest to fix.

I have a actually a recorded demo of this one. Uh just wanted to play this. Before I do that, I wanted to make sure we have the volume Uh, do we have the volume I have the full volume over here. It's not uh coming up. Does it have any volume? >> It's the volume is not coming up. I mean the sound >> because this is a a

recorded demo. I need to play this. Is this the one? >> Oh yeah. >> Oh my god. Use this. Not this. Doesn't have. It's here. It's here. Is it plane? evolving the core of policy validation and the rule rule engine logic will remain the same across all editions. Any differences will be limited to advanced or optional capabilities and not to the fundamentals. So what what you're seeing

today is the community edition. To use it, you will need to host your own policies before validating any Kubernetes resources. So this version is still in an early adoption phase and at this stage my primary focus is learning from real world usage rather than fully productionalizing the community plan. The goal right now is to keep the policy management simple while ensuring that the underlying enforcement and validation

mechanism are robust, scalable and future proof. So I would really encourage you all to try it the GitHub issue link at the end of the session. So please feel free to report any kind of an issue, any kind of a suggestions, improvement or any any request for new features. So garden is totally open source and the contribution to of any kind are welcome whether that's a like

a feedback design ideas feature suggestions or any kind of a direct code contribution. So I'd be more than happy to welcome more community members and build this together. Now without any further delay let's deep dive into the demo use cases. So once the chrome extension has been installed you can see that here over here in the list of extensions and in front of the extension guardon you

can see there are three dots. Once you click on that you will see uh options. Once you click on that it opens up a page a new tab where it says guardon policy manager. As I mentioned before, this is a community edition and you are responsible for managing all the rules. So that's where this page has been developed where you can add all kind of rules. So

we'll go over uh the different uh kind of rules that we we can add. We'll see all of them one by So at the at the left top corner you can see there are three buttons. The first one is to add a rule. So when I click on it, it just opens a panel where you would have to define the fields for a particular rule starting with

the rule ID that's a string. So you can have anything over here. The next one is description. You describe about what kind of a rule this is. The third one is a YAML path. So in your Kubernetative YAML, you would have different fields. So you need to specify the path to a particular field separated by dot. And then the fourth one is a pattern where you match

uh whether you would uh need a specific value in that field or a specific pattern in that field. So that is the fourth one which is the pattern and it's in reg x form. The next one is a kind which is pretty much predominant from uh the kubernet schema. So any kind of uh the kubernetative resource that you wanted to verify which is it's a deployment or

it's a po it's a pod or it's a stale cell. The next one is a field called required which has a boolean value either true or false. So I I categorize the rules mostly into two categories. One is where which which would say that you need a particular value. So in that case that required field will be true. Whereas the other rule says that a particular field

value should not be there. For example, an image tag like latest is not allowed. So you would say false for that particular matching pattern. So in that sense the required field make uh make you'll have to add it as false. And we'll see all this with an example u when we import the rules. The next one is the severity. So you can define uh a rule as

a warning, as an error or as an info. And the next one is message. So you need to just specify a message what the user would see when the rule is triggered. It's it's more uh of explaining what kind of rule it is, what is needed. And then there is a checkbox called enable which will allow you to enable and disable rules. So for example, you wanted

to disable that rule for a time being. So you can simply uh click on this checkbox, disable it or you want to keep it enabled then just just check it. The next three fields are a text fields. Um the the first one which says the fix. So this is very interesting because uh when you have uh a policy violation or a validation which has failed, it's it

becomes important to explain the user that what kind of uh what kind of fix needed over here. So this particular field will allow you to add a JSON structure uh here and you will you'll provide the fix directly into the validation. So that means when you open the YAML file it will or when you open the fixed YAML file it will show you the complete structure of

the YAML file with the fixes. So that this particular field would would make that enable. The next one is the rational uh which is again an optional field. So you can uh specify uh like why this rule exist and referring to the site of uh whether it's a CIS, NIST, Qno or any kind of an internal documentation. And the third one is also a kind of a

reference. So you can provide a link to any of the documentation whether it's internal to the organization or it's a standard document. So you can pretty much do all that uh for the rules. So this is a highle structure of the rules. The next button next to this one is uh an import rules. So here I have two options. One is I can choose a file that

has to be in a JSON format. So I can import all the rules which are specified in a JSON format. And the next one is to provide a link. So this one is particularly for the Kerno use case. So let's say your organization is already using Kerno as a policy management tool. So you have those policies and you wanted to reutilize that uh in guardon. So you

would just have to use the link a GitHub link. So once you provide a GitHub link to that given no policy it will fetch that and convert it into guardon specific rules and you can import it directly. So we can see those two things uh one importing a particular uh JSON file which contains rules. So I have a list of uh rules which are listed over here.

Uh I have this file already into the uh GitHub. So I can simply import it over And once I say import it pretty much converts all that JSON uh document into my garden specific and I can I can show that on the screen. So you would see this over here um as I was explaining about uh the particular field. So what a particular a particular rule. So

you can see over here you can click on the edit button and you will see that all the rules are listed over here. So all the fields um like ID is defined as particularly for this rule it's required resources and the description is simple requires CPU memory request and limits. The YAML path is specific to a deployment. So that's why it says spec template and then under

the spec you have containers and the list of obviously list of items over there in the containers. So it's it's asking for resources. So if the resource is needed over there that's what this rule is says and then uh severity is defined as error a simple message that will appear when the validation fails is going to be container must define both request and limits for the CPU

and memory. And as I was mentioning about the fix, so you would see that a JSON kind of an fix is provided over here. So you will see that when we validate uh a deployment file, a deployment YAML file and it has this kind of a violation. Then how does this fix work? So we'll see that. And then simply I have for the sake of demo purpose

I have just listed a a link over here to my own uh GitHub repository and then uh again for the reference this is just for the demo purpose. So that is uh what the rules look like. Um and similarly as I was talking about the other option that we have over here. So I have a uh give no policy link over here a GitHub link and I

have opened it in a raw format. So I copy that and then I go to the garden policy manager and put it over here. So when I say this refresh it says that it fetched the content into the import area. So you can see that it is being fetched over here. And when I say import, it just gives you a preview of what exactly the the given

policy has detected. So it says disallow host path and host path. So this is a simple example. So the host path volumes are forbidden. The fields spec volumes host path must be unset. So that's what the rule is saying about. So we simply import it. And now that you see that the total uh count of the rules has gone from 28 to 29. So this is again

a kind of a utility information over here which gives you how many total rules are there uh how many of them are enabled how many of them are disabled and then another utility beside this is you can search the rule by its ID description or anything so this is to provide a flexibility in terms of uh searching the rules and how many total rules are there when

there are more than like let's say uh more than 30 rules or more than 40 uh going into multiple pages. So it will be easy for you to search those rules. So now that we have these rules defined, let's reutilize them uh in validating the the YAML files, the Kubernetes specific YAML files. And since I have a lot of rules which are applicable to deployment, the Kubernetes

deployment object. So let's take an example of a deployment. This is a uh demo repository that I have under my uh GitHub dev or so. So you can pretty much utilize the same thing. Uh it's a very simple YAML file uh for a deployment. And once you open this in GitHub, you can simply go on and click guardon extension and it will give you this popup which

will give all kind of violations according to those rules. So you can see over here there are 16 violations out of which there are nine errors, five warnings and two are enforced and then it also says that uh there's a schema based validation but ultimately there is no matching schema that means the YAML itself the the guardon does not understand the schema. So because we haven't uploaded

any any Kubernetes specific uh schema file. So so far uh it says 16 violations and if you can take uh any of these examples like uh let's say required resources. So it says the limits for CPU and memory. So that rule that is not applicable over here because uh the resources are not defined. So that means um this is a violation and this is defined as an

error. So now if you click on this one this icon which says preview patch so it will give you a detail of like how this YAML file should ultimately look like when the resources are added. So you can pretty much copy that YAML file or if you wanted to download it you can download it and then finally just close it. The other icons that I have over

here are u basically directly you wanted to just copy the snippet the code snippet over there or if you want a little more information about why this violation then as I was describing about defining those rules you can have those boxes where you can define kind of an explanation that you wanted to put for this validation. So that is there the three action buttons that we have

for all the rules. If it is not there like for example the information I'm missing so you won't see that icon but for most of the rules you will see this uh two icons. Um some of them may not have it uh because we haven't defined those uh code snippet in YAML format in JSON format. The other utility that you simply over have here is just copy

the complete report. You can copy it or if you wanted to take a different uh look and feel of this pop-up then you can change the theme. It's a simple uh button over here and uh if you see total 16 violation and we don't have any schema over here. So now what we'll do is we'll go ahead and upload a schema file. So if you see look

at over here there are um there are three buttons over here out of which the first one is the import kuberneti. So once we click on that it gives us an option to select a file. Again I'm going to select one of the file that I already have in my demo repository. So this is an open API spec for kubernetative version. And I do have two fields

over here which uh which tags this particular open API schema with a particular cluster. So I can say it's a broad cluster or dev cluster and I can define it as a particular version. and then just say save. Once it saves, I can see there are two entries which are pretty much similar. This is because uh I have a duplicate entry in my file. So I'll just

remove one for the sake. And then when I go back again in validating this YAML file, I simply click on this icon once again and it again gives 16 uh violations. But this time it doesn't say the schema is missing but says that the type mismatch for the specific replicas expected integer but got string. So you see that the replica over here is defined as a string.

In case of the open API schema, it has to be an integer. So that's why the rule fails and it lists over here. Now so far we have seen that uh when we invoke guardon on any of the GitHub pages, it automatically fetches that YAML file and validate against it. But let's say if you wanted to if somebody invokes the guard on uh extension on the page

which is it's not a GitHub page or doesn't have a YAML file then it would say that no Kubernetive YAML is detected on this page but it does give an option uh where you can paste the AML file and validate it. So let's say we validate the same YAML file in a non- GitHub page the result should be same. Yeah. So it still says like 16 violations,

uh, nine errors, five warnings, and two info. So it's it's pretty much the same thing. So that's an option. Uh, if you don't have the YAML file or a GitHub page, you can still copy paste the YAML file and and do all the validation. That's an option. Next example is um a custom resource definition. So which is very much common uh in Kubernetes. We create custom resources.

Uh, for example, this one. Uh this is a YAML file uh for kind database and this YAML does have a problem. But uh Gardon as of now doesn't understand this YAML schema. So if we try to validate this um let's see what does it say. So I'll invoke guardon on this. So it says the schema validation. So no matching schema found. So which is which is right.

Right. There is no schema. So on the garden policy manager I do have a button uh at the bottom which says import custom resource definition. I click on that and I would choose a file. Uh this is again going to be uh from my GitHub resources. So I do have uh a schema file for this and when I upload get uploaded it says CD saved I go

to this one and now try to invoke guard on it says that the schema was found the schema validation a type mismatch for spec version expected string got number. So the version over here has to be a string but instead of that it's an integer. That's why it does report that. So that's an another functionality or capability with guardon that you can uh upload the custom resource

definition schema files and then validate against it. All right. The last part of the demo is to use open policies. So companies are adopting to open policy agents because it gives them a consistent scalable way to manage policies across increasingly complex and distributed systems. Open policy agents lets policy separate from implementation which improves governance and reduces operational risk. And to support this I have made use of

open policy agent web assembly module. So the web assembly or WASM is a low low-level binary format that lets you run high performance code safely inside the browser or other runtimes. So the first step is to have your policies written in reggo format and then compile it into a binary which is compatible to run on a browser or basically it's a it's avm file. So I have

a readme file which explains everything about uh the reggo policies and how do you compile the reggo policies into a WSM format uh which is avs format. Um I do have support here for the Windows. I haven't added it for Mac. I'll have to do that. Uh but you'll find all the examples and how to compile it, how to extract it and rest things. So you can

go through this one. Uh for the sake of the demo, I do have a already compiled policy already avail. So let's take a look to that. So on the on the guardon policy manager page, you can see those three buttons at the bottom. The last one is to import the OPA rules. So when I click on that, it gives me an option to upload a file. And

when I click on it, it again uh gives me an option to upload avm file. I do have it compiled in my demo repository. So you can pick it up from there. Um and before I do that, I also wanted to show you that the reo file that I have over here uh which is this one. It has uh somewhat four rules which is pretty much similar

to what we had in the uh the guardon simple rules. So it's related to deployment. All of them are related to deployment. Uh like the container is missing the CPU request, it's missing the memory request. So those simple rules are there in this file. I have compiled that into avsn file. So now when you try to upload that So once I click on save you will see

that it appears over here. Now what what garden does it it stores the bite locally and loads them via small open policy agent VSM runtime which is an opa vom bundle.js. JS. So when you validate YAML, we'll see that how it works. So let's go back to our repository and just pick up the same sample which is our invalid deployment. And then I again click on guardon.

So now you can see instead of 16 I have 17 violations. So I go all the way down and here you will see that my open policy agent has kicked in. Uh the policies are getting executed on the browser itself. So what it does is when you validate a YAML guardon turns the document into a JSON pass it it as an OPA's input runs the VSSM policies

entirely in the browser. So there is no network calls and then merge any decisions or violations returned by the OPA into a small in the same result table as guard builds in and then you can see that those uh all the results over here. So yeah that's it uh for this demo. Thank you for watching. Yep. I mean, uh, that's that was the demo on, uh, version

five that I've built so far. Um, there are some, you know, kind of an enterprise concerns. Uh, I can highlight like, you know, at this point, I want just wanted to explicitly acknowledge a concern that comes immediately in enterprise discussions, right? So, uh in the current version the guardon uh as an individual user you can still go ahead and install it it's available on the Chrome web

store uh but obviously for the enterprise version which I'll be working on uh would require more control uh because it's when if you'll try to install it any if you're in any organization you're trying to install it it won't allow it right so and this is not a flaw uh it's basically uh you know it's deliberately uh basically about bootstrapping the choices and uh not intended at

that state. So the purpose of the current model is to just validate the core hypothesis uh the review time review uh visible enforcements and you know meaningfully improve feedback latency and remediation behavior. Uh and on top of that I mean obviously uh we are looking at uh AI and uh the agents AI agents which will be doing a lot of reviews in future. So there is again

a difference of uh difference on a lot of things where uh if you look at any any u regulated industries right they won't just have these AI agents making decisions the the existing policy engines like kivero or uh open policy agents would still play a crucial role in having the decisions making those decisions as a as an important factor. So the the agentic AI could be uh

one of the one of the you know governance layer which would act as a uh which would act as more of a suggestive right because they are good at doing the prediction part of it right so I I see that uh in long run it could be a a layered governance I can say where um at the top layer you can have AI uh providing all kind

of a probabilities and feedbacks. I see guardon can still be um you know leveraged by AI agents because uh garden is gardon is actually leveraging those existing tools which play a very crucial role in governance. So all the policies that exist using these tools, we are just bringing that to the review time enforcement and the agent can still depend on this to produce those results to give

some suggestions as I was showing in the demo that there are uh you know when on a particular uh failure or a review failure or a policy violations you have three buttons which gives you a a feedback right what kind of fix can be applied on top of it. So similarly uh uh it comes those feedbacks comes from those policy engines and that can be leveraged by

the the agentic AIS to uh to surface it back as a proper feedback give you more reasoning about So yep uh that's pretty much it. Uh I'll just open it for any uh question and answers. >> okay, is it possible for other team other companies to get this tool and get their own policies and use your tool? What's the input for your to prepare the policy to

import to your to your tour? is a JSON or yam format policy file. >> Uh I didn't get the question completely. uh you mean like uh >> if for example if our host want to use your plugin and how we can use it how how we prepare the data the policy to >> so uh okay so this is uh basically right now it's an extension a chrome

extension you can simply download it uh but as I mentioned in uh that uh right now in this version the community version you'll have to build your own policies right but in case of enterprise version there could be policies which are already existing. So in that case you might have to have uh you know uh either preloaded or cache those uh policies in your browsers. So it

may be that you might have those policies pulled into your GitHub repository loc loaded them into your local machine. But yeah that could be for the enterprise version for the community version you will have to still write your own rules. >> Okay. So suppose we have our policy in PDF files or what document do you have tool to convert to prepare the input for for your tool

to import? >> Yeah, you'll have to prepare that because right now the tool accepts any JSON format, right? So you'll have to convert that into JSON format to to fetch it and upload it. >> Okay. Do you have some AR tool to do this kind of automatic conversion from >> but those policies have to be you know uh it has to be technically sound for the tool

to understand it right. Uh right now the policies it supports is keyo which is cloudnative policy engine. So any kind of those policies either in YAML or JSON format which is technically correct and relevant for the Kubernetes that can be imported. So you'll have to whatever policies you'll have it has to be specific to Kubernetes. >> Okay. Okay. Yeah. We have thousands of policy documents in hospital.

>> Okay. Well, thank you very much. >> That concludes scale for 2026. See you next year.