 Hi, everyone. My name is Dolis, and I'm working for Nirmata. We are actually the creator of Kivarno. I'm flying all the way from Halifax, which is in Nova Scotia, Canada. And so far, I'm enjoying Chicago. So today, we are going to talk about how you can automate productionary cluster using cross pane composition and Kivarno. Folks, we've got some space here, so you can accommodate. So let's talk about a little bit of agenda of what this talk is all about. We'll talk what is actually productionary cluster and why do we need to automate productionary cluster and what the workflow looks like with cross pane composition, how can cross pane composition looks like, and how it can help you to automate all of this stuff. I'll give you a quick demo of the entire workflow, and then I'm going to talk a little more about what are the challenges in the current workflow and where Kivarno comes into the picture, how you can help in this entire workflow, how Kivarno can be helpful. And I'll give the same demo with cross pane composition and Kivarno together. So to start with, let's talk about what are productionary cluster. So the heading of this talk was automate productionary cluster. And the question might be like, aren't they similar to normal clusters? Like what is production ready? So when we talk about productionary cluster, we have some kind of parameters that we always consider. It's just not like spinning any cluster and calling it production ready, right? When we call a cluster production ready, we make sure that we are entirely designing the sizing. We are taking care of the entire architecture. We are designing the size. We are making sure and considering what workloads we'll be running on this cluster and make it customizable or designing it that way, right? Once they are up and running, then we start thinking about what are the add-ons we want to deploy? What are the monitoring tools for visibility, backup and storage? What else? It can be like, okay, backup and storage, monitoring for security, what are the add-ons we want to do? All these add-ons we decide and we create a cluster add-ons for these production clusters. Once these clusters are up and running, we figure out what does the access management looks like? Who can access this cluster? What does the security looks like? What does the configuration of the applications look like? What are the best practices we try to figure out and consider it? So it's just not like normal clusters. These are like making sure that these are ready for production. So we are going to talk today about how do you just not automate any cluster? How do you automate all these parameters that make the cluster go live in production? And why do we need to automate production-ready clusters? Now, I'll dig deeper into why do we need automation? Because all of us know why we need automation. We talk about it again and again. Why do we need automation? It helps you for DR and it helps you fail our process, just going quickly through the points here, efficiency, scalable, you can do it again and again. Right? It's auditable, helps you to reduce misconfigurations, ease of management, all that pretty good stuff. But why do you want to automate production-ready clusters? Why do you want to automate cluster creation to start with? So here, what we want to do is we want to automate the setup so that we can provide, we can give self-service to the developers. So what we can do is, when we automate this entire workflow, what we are doing is, we are enabling developers to create their own cluster. And remember, the word here is enabling developers, right? We want to make sure that we give them the control that they can create their own cluster. The infrastructure expertise don't have to create clusters for developers. They can create an environment which is reliable and good enough so that the developers can create their own clusters. So all these things when we want a cluster or whenever a user or developer wants a cluster, creating cases, going back and forth, all these frictions, you can push it down and they are visible and they are self-reliable and they can do all the things of their own. And that's the main point of actually automating productionary cluster. So all of this can be done using cross-plane and we will talk more about how cross-plane composition can help you to automate productionary cluster. But before jumping directly into the cross-plane composition, I'll talk a little bit about how cross-plane can be beneficial to start with. So cross-plane is an infrastructure as a code tool so it can help you with all the IAC capabilities. Now, what are IAC capabilities? It's infrastructure as a code. That means you can create infrastructure using code. That's cool. You can have that entire code in your GitHub. So you can track it, you can do version control, you can do rollback, you can troubleshoot, you can audit, scan it and see if it's secure enough and all the cool stuff we talk about when we talk about IAC. So cross-plane gives you all of that. Cross-plane is native Kubernetes integrated. That means now what you're doing is you're enhancing your Kubernetes power to create your cloud computing resources in cloud. So now your cross-plane will be running in your Kubernetes cluster and you're enhancing API to go and create resources in cloud. Cross-plane have something called as automated reconcilation. That means if somebody goes in the cloud and deletes this EC2 instance which cross-plane was created, it automatically reconcilates. So you don't have to worry about, oh, where should I store my state files? Or, oh, somebody related, should I just sync my state file and all that? All that things is something cross-plane will take care of it. It automatically reconciles stuff. It has resource abstraction and it has complex frameworks to handle and create multiple infrastructure in your cloud. And that's where when we talk about adaptive framework, complex framework, that's where composition comes into the picture. So when we talk about how do you automate it, that's where cross-plane composition can help you with. So what's cross-plane composition? So cross-plane compositions are basically a template which you can use to create multiple AWS resources, treating it as a single object. So you can have one template that you can trigger and in the backend it will trigger 10 different resources for you. So for example, you have a use case that I want EC2 instance. I want my S3 bucket. I want my RDS. This is what my application stack look like. You don't have to have 10 different YAMLs for cross-plane and trigger that. You can have one composition file, have everything over there and there you can have just one claim file that can be used to trigger all those 10 different resources. So that's where composition helps you to simplify all of that and makes it less complicated. Now this is a diagram that I have over here which tells you what this composition looks like. You'll see there are, and this is very specific to how it works in EKS cluster, but you can replicate the same for EC2 instance or any other cloud resources. And on the top you'll see a cluster claim which helps you to trigger all the other resources you are seeing beneath. Now to create a composition, what does you require? You basically require a template that will define what resources you need to create and then you require a composite resource file which has all your configurations of your resources. So it's not very complicated to entirely set it up. So let me, enough of talking, I'm gonna just show you what does that look like. It will give you a more clear idea of what does that look like. Okay, so before I jump deeper into composition and show you like this big lens, the YAMLs and just bore you with that, I'm gonna start with a simple EC2 file that can help you understand how CrossFit works and then we are gonna dig deeper into compositions. So this is a simple YAML file which helps you which you can use to create an EC2 instance in cloud. If you look at this YAML file and that's where we keep on saying it's Kubernetes native because it becomes very simple. It cannot be more simpler than this. It's just basically a YAML file. You can put all your resources, you can put your region, image ID, all the different things and you just apply this and that's where your EC2 instance comes into the picture. Now you'll see the provider here is AWS config. So if you wanna do it using Azure, you can do the same using Azure, you can do it using Google. So you know like I'm a AWS person and when Azure came into the picture, I was like okay, how do I create EC2 instance in Azure? And I was navigating all in the UI, like going through the entire platform. So you don't have to do that. Once you have this YAML, you just use different, different providers and you create the same resources here and there, right? So going into the composition, this is what the composition file looked like. Now let me walk you through what does that look like. So this is a composition which has all the complicated, like when you create an EKS cluster, you all might know that it's just not creating an EKS cluster. It requires VPC, it requires three different subnets. It requires route tables, roles, node roles, X, Y, Z, A, B, C, D, E, F, right? So what you can do is all those things, you can just put in your composition file and you can have it ready and a developer can just use a claim file. You can, a developer can define okay, I need an EKS cluster and he'll just trigger that and all these on the surface gets triggered. So this is what we are looking at when we are talking about composition which has all the resources defined for you and you will see it has a node group over here. So it tells you like this is the node group and this is the region I want. So you can customize it, you can change it, again it's YAML. You can say this is the size of what it should be, small size, so here we are just defining T-shirt sizes kind of stuff where you are saying that small is T3 small in AWS language or medium is T3 medium or large is T3 large. So we are kind of like variableizing some of the things over here. You can do it, you can choose not to do it as well and some of the other things. So we do have roles here which you generally create using AWS. We have different kind of rules, roles, we have different kind of node roles, all of that things, right? Now if this YAML looks big for you or it's too long for you, cross pane has also introduced functions. So you can also have functions where you can define all of that and then you can call the functions. Well, I would still prefer this because it's copy paste, so you know, but if you don't like copy paste and you're from developer background, you just like functions and wanna do like cool things, you can do use functions and you can do all of that, right? So this is what the platform team will do. They will have all this set up ready, they'll have cross pane in their cluster, they'll have this composition file, they'll have this all deployed and everything will be set up. So I have that today entirely set up. Now let's look at what the developer workflow will look like and what will that self service will be all, I was talking about what does that look like? So this is a claim file I have and that's what the developer will be using to create an EKS cluster and the thing I was talking about which small means T3 small and all that, that's what you can see over here. So that's why I have defined and I have, you know, variableized it so you can make this as simple as possible for the developers. You can choose what to expose and what not to. So I can choose if I want to expose the node size, node count and name because I believe that's what my developers will require. But if you think that your developers will require maybe region or maybe you give them some more area to play with, you can add all of that in the cluster claim file and they can create a simple EKS cluster using this claim file. So I can show you how, it's just a cube cut a little command but I can show you how it is done. Maximize, I'm just because it's, okay. So it's just as simple as creating this claim file, just give me one second. I had some policies in this cluster. So this got created and this was my cluster name. So basically I had my cluster name as name of this and I have my, I have some parameters added over here and this was the provider I was using. So it got created. Now let me go in my AWS console and see if that got triggered. It should basically, perfect. So you see dollars is running over here. That means dollars has an EKS cluster name is getting created and perfect. So this all gets created and all the VPCs and all the subnets and everything I had was in my composition file. Developers don't have to worry or don't have to struggle with 10 different resources. They can just work with this sweet claim file we have over here and everything will get deployed on here. One thing that we are missing over here, we were talking about production ready clusters, right? We were not talking about any Dev clusters. So this is a simple cluster I rolled up. So your question would be like, oh, you're talking about production clusters. So what about these add-ons and all those fancy thing we were talking about? Well, control F, okay. So Crospin also have a Helm provider that comes up once you install Crospin. Over here, what I have done is once the production is up and running, I'm using a secret to fetch the kube config file because I have all the credentials and the basic setup ready. So what Crospin will do is it will also install all the Helm using this Helm provider. So here I have like Kiverno getting installed on this cluster that will be coming up. I also have Crospin that I'll be setting up so you can have your add-ons like monitoring tools, backup and all those tools we were talking about. Your add-ons are also up. So now you are automating your entire production setup. You're doing everything that you want. Cool, so this looks good and we discussed, I'm gonna go back to my slides and this was a little bit of what did that all look like and how we can automate it and this is what the workflow was talking about. Now, let's understand what are the challenges in the current workflow, right? I automated everything and I showed you an instance YAML file where you can use the same YAML and you can create an EC2 instance, which is good, but how do you make sure that instance YAML and the region you are specifying, your developers are not creating an instance or S3 bucket in a region they were not supposed to create or your EKS clusters are public endpoints, right? Or for an example, the node size we had, the node size, node count, nobody is creating a large node with nine count in some different region. So now I have automated everything but the next day I'm getting security alerts, cost alerts, my boss is calling me, telling me, okay, you are automating all of this but it's not good, it's just a lot of alerts and you have no control. So the self-service that we are trying to promote is something gonna get restricted because we don't have any way to control it. So what we wanna do here is, we wanna provide a playground for the developers to play with but also we wanna make sure that we have a boundary around that playground so that we can control and watch and have visibility into that and all this we are talking about, somebody creating something in different region, me trying to understand, okay, who created something in North Virginia, we were supposed to create everything in North California, guys, all these things, we can just directly block it and avoid all of that. So that's where the challenges comes into the picture and that's where when we talk about automation, it never goes to production because we kind of struggle with these challenges in them and it's shut down, not going in production. So some challenges can be excessive privilege, we can have excessive privilege, people doing all kind of stuff when we are talking about self-service, security and compliances, there is no way these add-ons you have any kind of check, anybody can create any kind of bad pod or privileged containers into these production cluster because we are providing access to them, right? And there's no consistency, there is misconfigurations all over the place and all kind of stuff, right? So that's where Kivano comes into the picture. Now, talking more about how Kivano can help you in this, I'll give you a quick introduction about what Kivano is. So Kivano means govern in Greek language, it's a CNCF incubated project, we have large amount of policy set in our website and we are most popular by stars in terms of policy engine. We are Kubernetes native, that means just like cross pane you can write a policy in simple YAML file, you don't have to learn anything else, the learning graph is not too much, it is we just don't have validated policy but we can do more than that, so we do have generate policy, we have mutate, we have image signing use cases, cleaner policies and all that stuff. So one simple example of generate policy can be that, okay, if one of my namespace gets created, create request limit, create quota, create network policy, create three more resources. So that could be a good example of generate policy or okay, with this namespace tag all my pod with this namespace or with respective namespaces that can be a muted policy. So you can do all kind of stuff and you can use Kivano CLI in your CI CD pipeline to scan all these IAC thing, right? Or you can use different kind of use case and you can automate multiple use cases using Kivano. A little bit about Kivano it was, now let's understand how Kivano can be beneficial in IAC or specific to this use case. So when we talk about IAC it's cool because we are using code and we are putting it in GitHub and we are kind of playing around with this infrastructure as a code and you know it all looks good, but there are some kind of security risk happening over there as well. How do you make sure? Are you scanning your IAC code or in your GitHub pipelines, do you have something that's scanning and making sure that things get blocked which are not like misconfiguration doesn't happen or things get blocked if they are badly configured? So all these security challenges is something Kivano can help you with. Kivano also comes with CLI so you can integrate it with your CI CD pipeline so it can scan your entire IAC and it can tell you what's bad and what's not so bad, right? It can automate your policy enforcement so it can deploy policies. So in this new cluster that I created which was named by dollars I already have Kivano policy deployed. So I don't have to worry about somebody coming up and having a bad part or privileged part. All the policies are running over there so I'm good, my security is in check not only on my managed cluster but also the new cluster that I created. So when you use the CLI and you kind of scan it before it goes to the production we are kind of like shifting left with security because now what we are doing is we are kind of getting early detection of what is misconfigured in your IAC or in your deployment YAML rather than getting it deployed in Kubernetes cluster and then thinking what to do about it. You can use it just like IAC you can use it policy as code so you can have all these policies in just like for IAC capabilities we talked about it's auditable version transparency all of that can be done using policies as a code as well. It also have background scanning so if you are wondering okay I deployed Kivano today but I had some configuration deployed yesterday what about that? So it does a background scan of everything that was deployed in the past and give you a report and we talked about validate, mutate, engendered so I'm not going to repeat that. We do have two modes of Kivano so you can run Kivano in enforce mode or you can run in audit mode so if you want to enforce your pods and if you want to enforce all the bad pods you can use enforce mode but if you want to take it easy and just to audit mode and just start with that you can have it audit mode where things will not be blocked but you'll get a policy report and you'll know what's happening in your cluster. Okay so I'm going to show you the same demo and I'm going to walk you through a little bit of Kivano policies how do they look like and then we will... Okay so I already have policy so these are some of the policies that I have specific to this use case now you can extend it to whatever you want we have many different kind of use cases out there. Now this is what I am restricting in terms of node size I'm saying that nobody can create a node size with large so everybody you should create something with small and medium I want my cost to be under control so nothing with large instance size is something that I'm creating. If you look at this policy it's simple YAML policy as I was saying it has like what we are using it's name bunch of annotations I have and then it is it enforce or audit I want to enforce that means I want to block it and it's background true it's going to scan it and then these are some of the rules which is going to apply to and then what I'm trying to do over here which is saying that anything which equals to large just denied over here that's that's what the validate rule is I have something else as well in terms of node count I'm saying here in this policy it's again a simple YAML file but if you look at the rule over here which this is a little important here is it is saying that anything which is greater than three node size should not be allowed so developers I can I'm assuming that developers will require something with three node size should be fair enough so you can only have three node size anything more than that it's not you can have you can make it four you can make it five but at least somebody will not deploy 11 node cluster or you know big sized cluster for you here is one more similar stuff it's just I'm saying that the cluster name have to have some kind of syntax that most of us following organization production cluster start with prod hyphen that start with everybody have their own syntax so I'm I'm just having a valid policy with syntax saying that all the prefix key is something it is checking everything should have the cluster name should be starting with dev hyphen and nothing without dev hyphen cool so let me show you let me deploy this policy and show you how does that work this is right folder I'm not that clumsy it's just that you guys are looking at me while I'm typing so it's making me a little nervous or you are here I'm just kidding okay so I got this policy over here it's a enforced policy and stuff perfect so what I'm gonna do is I'm gonna deploy the same YAML that I tried deploying the claim thing again and I'll just show you what does that look like right like I have my and I just have my one policy so I have my restrict node size I'm saying that nothing with large node should run up so I have deployed a policy it's an enforced mode all set up there I'm gonna just run this claim file and it will clearly tell you that my friend you're not allowed to create this cluster you cannot create a cluster with node size large please change the node size to small medium and you know come back again right so this is one example you can do multiple such use cases using Qverno and you can automate your production cluster using cross print composition and Qverno so yeah I think this was what I wanted to talk about now I'm gonna open for questions and yes yeah so yes and I'm asked to repeat the question over here so I'm gonna do that so his question is that we do have audit and enforced two modes of policy but is there a way I can have a dashboard or you know can just visualize that so we do have you can we have metrics exposed in Qverno so you can integrate Qverno with bunch of different tools in monitoring side with Prometheus you can have Grafana dashboard which will tell you healthy status of your policy it will tell you a policy count we have bunch of other metrics that's there so you can you can integrate with Prometheus open telemetry and couple of other tools and you can get a visualization of that so your question is that if you don't have any Qvernities clusters how it's gonna work oh yes of course yeah so what the bootstrapping okay so his question is that how does you have this entire setup ready how do you bootstrap all of this entire use case so you can you should have a Qvernities clusters that is Qvernities cluster that's that's rule number one then you should have cross print set up on that so cross print do have like a Helm Helm there so like a Helm thing there so you can just use one single command Qverno has the same thing so you can use Qverno using kubectl single command or you can use Helm and deploy Qverno and you can have policy so you can just apply policy the way I applied over here and then the composition comes with cross print so you don't have to worry about the deploying compositions or anything with it it will select two CRDs for compositions again but you do have to write your compositions that I showed you over here so you do have to write the entire YAML the composition YAML and that's it yeah so you can actually the state management and everything works similar way just you you make it work like kubectl right so this is the VPC I got created and it is it will tell you the ready state and all so how do you describe for today you just describe it so everything is same so that's how you can manage it exactly yeah saying is you can scan this code and give me feedback guys or you can okay I think we are good bye