Next guest, our next speaker is Christian Melendez. Let's reach out to Christian and see if we can get him dialed in here. Okay, here we go. Going to fly out from Prague. We're going to go see if we can find Christian hanging out. Christian, can you hear us? There we go. Christian, you are live here with us here at .NETConf. Oh, awesome. So, welcome. You're going to talk about CI CD pipelines for Kubernetes. Great stuff. Take it away. Yeah. The idea is that you can create a CD pipeline for Kubernetes using Azure DevOps. It has been rebranded to Azure DevOps from PSPS. Yep. So, I guess I should start now. Welcome, everybody. Let me start by, the decision is going to start with saying a typical story of how you will do the usual themes when delivering software. And then I'm going to suggest some things and how you can improve things. And later, at the end, I'm going to show you how to actually create a CI CD pipeline. So, let's start with a typical story on day one. A typical story is that then finishes coding and then puts changes to a control repository. Then someone or something else builds the app that is generated. It's compiled and things like that. And then the developer deployed to a non-production environment. That task is mainly by themselves. They have to have everything ready. They test, for example, in development environment, and they make sure that everything is working great. So, after that, now it's time to move changes to another environment. So, they're ready, they're confident that everything will keep working. Surprise, surprise. They just have difficulties and not everything works as expected, as you could imagine.  And they have to start working on trying to solve those problems. So, ideally, when they are trying to move that to, for example, a testing environment, they will run a set of tests that are executed, hopefully, in an automated fashion. And if everything is okay, they continue with the next environment. If not, they will start over again. So, this is a repeated cycle, but they have to spend, like, a really good time in trying to move things from outside, from their computer to a productive environment. So, this is day two, usually. It is not as easy as just copy-paste the artifacts to the servers. So, then comes the day three, assuming that everything worked as expected. And then, since I mean DVAs and security poles are called, they are called because they need to check things and make sure that we don't have security holes in the application, that we are compliant with the regulation of the company, the policy that the company has. And the DVAs has to check that the script that we are about to deploy are working, and they have we are not going to truncate a table or drop a table. So, it's always good that they get it all. Developers then need to change code again. This is usually the normal way, especially if this is a big change, but if we are talking about small changes, this usually doesn't take too much time. But let's bear in mind that we're talking about doing big, big changes. Then CSUN means, and DVAs deploy changes to production. And usually, after that, CSUN means developers versus everyone that fights the stars. Why? Because CSUN means are trying to have a stable environment. Developers are trying to push the changes as soon as possible because they are being pressured by management and so on. So, the thing is that you will have a lot of problems when there are silos and you don't have a good communication with the things. So, there has to be a better way, right? Actually, there is. So, let me share with you some of the things that I've been reading about on my blog on how to make deployment smoother. This is based on a book that I read a few years ago from Yes Humble called Continue Delivery, which I would recommend you to give it a try to that book. And basically, in that book, the things that you will get as a recommendation is that you should automate as much as possible. There are trade-offs, as always, as with everything, but try to automate those repetitive tasks that are boring, basically. Build compact your application only once. This is great stuff because you don't have to worry about building and compiling again in another environment.  So, the idea of building and packing your application only once gives you that confidence. Deploy the same way all the time will let you feel more confident. It will increase your confidence on deploying things because once you work in development, it should be the same. It should be working on a production environment. And I mean, I really mean with this because I've seen many problems with workshops that are not doing... They're not applying this rule, basically. They are treating a production environment really special and they think that, well, development, we can do whatever we want, we can install whatever we want, let's give access to everyone so they can play around with that environment. That's the developer environment. And so I agree with them. It is not always a good thing that you don't have a way to practice your deployments to production. So, as long as you have a non-production environment in previous environments, you'll be all good. Deploying small batches and do it often. This sounds like really easy and actually it is, but what if I haven't finished a feature or if my working or if my code is having problems? Well, there are some strategies that you can implement in your code that are called feature flags. So if you need to deploy something because you need to fix something and you don't want to revert your code and create branches and things like that, you can always turn off the flag and you will be practicing that deployment. I've been experiencing that in other projects where we are deploying the changes to a big change in the architecture little by little. And it has worked for me. So that is a recommendation that I can give you today. Choose a zero doubt strategy so that the customers, your clients will notice that you are changing something. Some of those strategies are called blue green deployments, counter releases, et cetera. This is a not common practice trunk based development, meaning you shouldn't be what? Oh, just humble. Yep, cool. So as I was saying for the trunk based development is not usually a common practice. I didn't know until I wrote an article about this topic. I received a lot of comments there that why should be doing trunk based development. Branches are good. They work. As I agree with them, what I don't agree with the approach of having branches is that you will keep branches for a long time. You are good to go with branches as long as you keep them short. The lifetime of that branches is short. That way it is easy and it is more smooth to implement continuous integration. That's basically the idea. Notice, I'm saying that you shouldn't be using branches never. It's just that for continuous integration trunk based development is a really good practice. Finally, work with environment variables meaning that as I was saying before you will build them back to your application only once. How are you going to test that in other environments? The way that you're going to do that is to work with environment variables. Basically, these are the recommendations that I have for you. How can you do that is the trick and that's why we have Kubernetes containers and that's why we have tools like Azure Dell that will help you to implement all of these practices that I'm talking about. Let's start with Kubernetes. I'm going to do a Kubernetes quick up. I'm not going to spend too much time here because I really want to show you how to create a CI-CD pipeline and that you can see what I'm meaning with all the points that I previously was talking in practice. Let's start. Why Kubernetes? Kubernetes is really easy to have in mutable infrastructure. You won't be curing too much about this is server A, server B, server C. It will matter because what will matter is that you can turn off that instance turn off that instance and you can spin up a new instance, a new server and everything should keep working. Same with containers and pods. If you're having problems you can easily terminate that or remove them from the load balancer and investigate there. The idea is that you don't spend time trying to face things as you normally or traditionally will do. Just spin a new server or a new container and that's it. It's scaled out very easily. You can have a state definition in file like meaning that Kubernetes is mainly based on a state. You can define the state that you want for your application and I'm going to do that. I will say that for this application I want three replicas and I want these three replicas to be exposed as a service and that service should be a load balancer, for example. Kubernetes will make sure that all the time the application has three replicas that is exposed as a service and is a load balancer and is public or is internal and so on. You can run local and that means that if you can run local with Kubernetes you can run anywhere. Now that Docker for Windows and for Mac has the support for Kubernetes natively you can create you can host your Kubernetes environment locally and that's basically what I'm also going to do today. I'm going to test my changes locally with a Kubernetes instance locally on my machine and then I'm going to create a pipeline to push that to another market. Rollbacks are very easy because you just need to say okay let's update the service, let's update the deployment with the previous version and Kubernetes will make sure that you can that you won't have a downtime there because the default policy is that Kubernetes will update your containers in a level manner meaning that it will be doing running updates not everything will drop everything and will bring everything up again. It is pretty safe. You will have high availability because I was saying before Kubernetes is mainly based on state how Kubernetes does that Kubernetes has HED where it's a no SQL database where Kubernetes stores the state cluster. You will find there how many know how many workers the cluster has how many containers how many pods, how are they configured and things like that. You can easily configure security controls for your applications and you can do a lot of more things but this is just a quick recap I'm going to stop there. The Kubernetes architecture is as follows. You will have Kubernetes master nodes which this is usually called control nodes and the ideal scenario is that you have three servers here. Then this control plane will expose an API where a user interface and a common line interface will interact with Kubernetes and on the right side you will find that you have worker nodes where all the containers or the pods will be hosted and it should have access to an image registry or a Docker repository. It could be something private, it could be something public, like as we were speaking for Gitco. Kubernetes capabilities and this is really the the powerful thing from Kubernetes because you can implement something like something like this as you're seeing on my screen where you can have a service exposed to the public and you can work internally on how to promote changes. For example you could have internal set of services and pods that only your team will test like a UAT environment for example then you can promote those same changes meaning that you will update the service with a new version of the container image for a canary in a canary way that only your free users will be experiencing and that will be only 5% of your users then if everything keeps working as expected you will promote your changes to a canary for your paid user but you're not going to do it for all your users. You can do the proper configurations to promote those changes to a service that only receives 100% of the traffic from your site. Then if you have tested everything in three different ways everything should be working right so you can promote those changes to production environment and that will be 100% of the traffic. You can wait as long as you want between these steps you can wait for an hour or two hours or if it's a delicate change you can wait for a longer time but it doesn't matter the idea is that you can do this with Kubernetes. So basically as I was saying before you need to spin up three masters and things like that actually I would recommend you to play around with Kubernetes the hard way it's a tutorial I didn't put the link here but I can share it later where you can spin up Kubernetes at the hard way, at your way by setting up the instances by your own configuration certificates and things like that and you will notice that you want that's something you don't want to have so that's why you will use services like this Azure Kubernetes Services where Azure will take care of all the master nodes for you and the good thing is that you don't pay for them you only pay for the worker nodes and that's a really good thing it integrates with other Azure services very easily you can create a cluster in Minutes and actually I'm going to demonstrate that for you because I don't have too much time I'm not going to wait for the cluster to be up and running it supports AirBug purposes and it has integrated login and monitoring and many other things that are out of scope of this stuff so let's keep moving how would you do DevOps with Azure? well now you have DevOps Azure product which previously was named as BSTS the good thing for Kubernetes is that you can have agents anywhere and I'm going to explain why that is good in the demo you have native Docker support integrates easily with any cloud integrates easily with Kubernetes even if you install for some reason Kubernetes the hard way you can build once and pull it anywhere and has extensions for common technologies like Terraform and things like that so in a DevOps world you will have pretty much everything you need to implement your CI CD pipeline and we're going to practice what I just told you before how to make the pullings smoother so finally how would you do this is like a improved version of a typical story with now that you are implementing DevOps this is like the end goal it doesn't mean that you will have this from the very first day although it will be good for new projects but the idea with DevOps is that you start working in small batches as I was saying before and don't get stressed if you don't have a pipeline from day one although it's very easily to create one this is a progressive improvement task that you need to be aware that you can start doing small improvements in the way that you are delivering the application how to deploy in minutes then you push your code changes to version control integrated in an isolated environment like Azure DevOps you build portable Docker image you deploy in a production like environment you run automated tests and repeat deploy and test again in other environments and when you deploy in another environment step one to three are not going to be needed anymore because you already have everything that you need packed in a Docker image and it is just a matter of pushing the changes to the environment so that's enough talking for me it's demo time so let's jump back to the console if you're not seeing my screen please let me know I'm going to create I'm going to show you how easy is to create a cluster you can have here service Kubernetes service and it's pretty easy I'm going to create here a new one and let's say a net demo and let's say it is going to use an existing let's use an existing resource group it's going to .NET demo and I'm going to write here .NET demo you choose the region you choose the Kubernetes version this is the version and you can choose the node sites the worker nodes and by default it has ds2v2 and by default has three nodes you can set up authentication here it will create for your service principle this is the you will need this to interact with other Azure services I'm going to leave this as default but this is where you can enable AirBug next you can enable or work with pretty custom configurations for your network but I'm going to leave that as default monitoring you have as I was saying before you have login and monitoring enabled by default tax if you would like to have tax for center cost and things like that you will wait a little bit as the service principle is created it will run a final validation and that's it you will have your after this is great I'm going to click here and I'm going to have my Kubernetes environment in just a minute so let's create this and that's it that's how easy to create a cluster with Azure so let's jump back to the one I previously created for demo purposes I'm going to create this is the cluster that I spin up for the demo so you can see here that you will have things like what is important for us now is that you have the access to that cluster and let me show you how you can do that you can say here like view Kubernetes dashboard install the Azure CLI you will need to log in if you don't have Qt controller installed you will need to install it then you need to download the credentials which I'm going to do right now you can run this command and it will download the credentials and it will change to you by default to the context to this cluster so let's jump back to the cluster and you will see that is going to create a tunnel where you can see that the graphic interface of the cluster that I just created or well that I previously created on Azure and this is pretty awesome because you have the dashboard interface pre-installed you don't have to configure anything and you will have here the usage, the memory the the workloads and so on the pods you will have the service here services here and let's jump back to the service that I just published an application that I used for demo purposes which here you can see that says .NETConf online the way that I'm going to do is to do this right now is that I will create a new change here and I'm going to change this and I'm going to push that but let's start first by going to to Azure DevOps and this is how you will create a CI CD pipeline let's start by creating a new project I'm going to create here a new print and let's call it a site for example I'm going to leave it as private but you can have it like fully and you can here you can choose if you would like to use Git or TFS or if you would like to have a dashboard work with iChile CMMI or Scrum I'm going to leave that as default because it's not the purpose of this demo right now and then it is going to have an empty code repository but I'm going to migrate the code from the code that I have here in my GitHub account it is not that I'm not doing this because Azure DevOps doesn't have support for GitHub but it's because I didn't want to mess with a working demo with a working demo code and I'm going to replicate things and you will see that it is the same experience that you will have as if you were working with GitHub so repos I'm going to click here to repos I'm going to import the code I'm going to click here and I'm going to copy this and because it's public I don't require any authentication and I'm going to import it it's way a little bit it doesn't it won't take too much time it is basically cloning the code to the repository here then the next thing that I'm going to do is that I will clone the repository to my local file let's go here and you can click here clone I already have configured an SSH key on my computer so I can easily do things like the things here where I'm going to close the proxy here because I'm going to come back to this later so let's go here and clone and it will download the code that I just migrated and you can see that I have the code here and it is pretty standard code let me open that let's here open and on site you can open that and as you can see it is pretty standard but I'm going to take the opportunity to review the some important files that we're going to use this is for example the docker file this is the file that it will use to build the docker image so let's say for example that I run here the docker build command I'm going to tag it and I'm going to create it with my username and I'm going to call it simple app and I'm going to call it latest and I'm going to say that the context is the current one oh wait I need to enter to so let's run the same command again has the docker file here let's see docker it was missing the docker build so it will as I already had these images these base images downloaded to my computer it will skip that and it will start to compile it to compile the application and while this finishes let me show you something here this is the docker format that I have running you can see that you can have Kubernetes here installed you can just click here click here and docker will do everything for you what I really like is that you have an easy way to switch back to the context for the docker desktop for example or you can switch back to the one that we have in Azure so I'm going to change this to the docker to the desktop version and I'm going to create a new window here let's see for example let's run this ctl getpots for example as you can see there's nothing there if I run this command previously I will see the pots that we're running in Azure so let's jump back here and let's create for example for some reason my environment is not working with local the Kubernetes cluster is not working when it's pulling the local images I'm going to push this this image to my repository as I said before this is not necessary it shouldn't be because you will use your local environment but for demo purposes I'm going to leave this but without warning so let's wait a little bit and you can see that it is already pushed and I'm going to go back to the console here and you will see that the latest version is there so now what I'm going to do is usually what I will do to test everything the command here but because I don't have too much time right now let's go back to the deployment Jamel here that I will use for Kubernetes as I was saying before you will declare here a deployment you will say here that you want three replicas and this is the image that you're going to use and this image this file is because it is in version control I'm going to change the latest version that the pipeline is created this is going to make sense of what I'm doing but because I don't want to change too much things to test locally I'm going to leave that as that so let's see how will you run that I'm going to deploy that luckily because with a command you will see you will see that it's creating the pod and you will see that it has created a service with external API as local codes so let's see how it is running so because it is exposed on port 80 and it is on local codes it should be working right let's go here directly and if I don't have anything else running on port 80 it should work and it works so I'm running this version of the application on my machine locally so let's jump back on how would you create something for because I was saying before that someone or something will build the application so this is how would you do this this is how would you create a pipeline you will go to Azure DevOps you will click here in pipelines builds and create a new pipeline and because I don't want a Jamo description right now to have this infrastructure let's go I'm going to use a visual designer so that everything that I'm doing makes sense for you and it is easy to understand so I'm going to choose the repository here but as you can see I can integrate it with any other code repository I'm going to click here on empty job and I'm going to leave that way I'm going to choose here I'm going to put in here the agent to because I'm compiling containers in a Linux in Docker for Linux so I'm going to choose that this is how it will you would see which break is pulling from this is going to be the pool of agents I'm going to leave that as default and as well as I did locally I'm going to this is the extension that I was talking about I should build the image and I'm going to choose this and I'm going to here create I'm going to start creating the connection to the registry that I have created here it doesn't mean that you cannot integrate very easily with Azure Container Registry in a private way but I wanted to do it this way so that you can see that it's pretty easy to do that next you're going to click here on manage sorry if I'm doing this too fast I'm going to create here a new connection to my docker hub account so let's click here docker registry let's here let's choose here docker hub I'm going to just here docker username my super password I'm going to verify that the connection is created I didn't put verified okay so the connection has been created and I'm going to jump back to the to the screen here I'm going to click here to update the connection and you can see that the connection is there I'm going to run the command build and if you don't if you're not sure about where is the file you can click here and you will see what the files you have for the repository you choose docker file and you will here put an image name so I'm going to put my username here and I'm going to put here simple app and I'm going to remove this and I'm going to change this let's copy this you will understand why in a minute why I'm doing this change this here to variable that I will create and that's it this is how you will build the image the next step is that you will push the image right so let's do this and let's choose here the connection this is where it is going to be very useful and you will here push it will change the text to push command and it should be the same image that you just built you should change this here and let's go change this so the next step is that remember that I mentioned that I'm going to change this the latest to the version that is getting built so that's why I need to create an environment that is version for example and I'm going to put it here one point whatever so let's go here save that and then what I'm going to do is that I need to replace that and I'm going to do it as simple as running on a command line script and I have the command here it is pretty standard set I replace it will replace what is latest the value latest with the version to the file the next the way that this process will communicate with the release is that it will publish the artifacts because I'm going to do the deployment the deployment that I have here to run the same command that I run locally in Azure I need that file so I'm going to put a name here I'm going to say for this for example let's say let's say that we only need to include in that artifact the camel to make it to leave it as light as possible let's here camel for example and let's keep that so I'm going to save it cube I'm going to save it on cube I'm going to keep using the default configuration that I had previously and this is going to start creating the build as you can see it says version 20 but that's because I already have other pipelines created here in the project and the cool thing here is that you will be able to see the logs in life and you can see every face what is doing and you can see this later also and it will initialize the agent it will initialize the job it will do check out the code it will start building the image but there's something that I'm missing here as this is going to take a while because the agent doesn't have the image as I already had in my computer that's why you will like to choose to have a hosted agent in your environment for for example in Azure so that this process is going to be more quicker so let's go back to the pipeline because I'm missing something here and as when we finish we're going to review that is working so let's go edit the pipeline and what I'm going to do is that after I push the changes in my code this will trigger a new build so it will it is as easy as going here triggers and you will click here enable continuous integration and I'm just going to save it and I'm just going to save it let's see if it already finished no but let's go quickly to create this is the CI pipeline let's create the CD part of the process let's create the CD the pipeline continue delivery pipeline I'm going to choose as well empty job and this is where I'm going to connect everything I'm going to close this here and I'm going to choose the artifact that I already built it is going to be the demo site that I just created it is going to be always using the latest version it would use these alias I don't care just leave this here and this is how you could enable continuous deployment trigger meaning that after the build is finished this release will be triggered so I'm going to leave that here and here just let me show you this you can have here pre-deployment conditions meaning that someone needs to approve this deployment this release and you can do that for other stages I'm going to hold it here development so it's clear why I'm doing this development and as well you will have agent job I'm going to as well use a bone tool and I'm going to start adding something as simple as Kubernetes you could have here the extension that integrates very easily with Azure Kubernetes service or you can integrate this here that you have somewhere else luckily for us this extension is already here and I'm going to integrate this with Azure so I'm going to here I'm going to say subscriptions that I already have if I didn't have this I would go back to the same screen as I was doing before for the Docker registry so I'm going to choose here Microsoft Azure sponsorship I'm going to click here I need to click here and authorize oh well it's closed and it is going to open a new pop-up window because I need to login to the Azure to authorize this so let's go here and it is going to be as easy as that I'm going to sign in then it is going to be then it's going to authorize to Azure DevOps to communicate with my Azure account so that's done let's wait a little bit here and after this finishes you will be able to see here the resource group you will be able to see the cluster that I created before and what I really like here is that you can specify the namespace of the cluster where you would like to deploy this change but if this is empty it is going to do it in the default so let's choose the resource group let's choose the cluster the simple app let's do it to the simple app that we already have let's leave everything as default choose configuration files you will then here get to choose the artifact that I finished creating as you can see here the deployment demo so I'm doing that because you don't have to worry about what to put here it is pretty easy to do that so I'm going to save this here and I'm going to click that and that's it if you would like to create a new release you will manually for example you will click here create release you will choose the stage you will choose the version as you can see it is the version 20 and let's create and you can go here to the release and it is going to be the same screen but the missing step is that you need to click here deploy you will here click here demo purposes for example deploy and that's it that's how you will create a pipeline the next thing but I don't think I have too much time is that I will do something here for example if I remember well it is going to be here let's change something here demo for example let's save it let's say demo and commit that change and let's push it it doesn't have a graphic way here but you will see here the code that it has a new change it has the demo change you will see that a new trigger is going to be a new build is going to be triggered there it is demo change let me show you just one thing here you will see that at my repo you will have the latest version and the version that it just built so basically this is the same it is going to happen the same thing we already see that the build is working let's see if the release is working good it is working let's jump back to the cluster for a simple app that I have in Azure and let's clear the screen you will see here that it is creating the new container and it is adding a new container image a new pod but it is keeping the other three that we already have it is running update see it is terminating the other pod and it is doing the deployment in a safely manner you can see here that I have the service and I have the external API as well here as I was seeing before in the console and the release won't finish because the build hasn't finished yet it is working I will keep seeing the same screen without the change but I am going to leave this here if you have any other questions if you have questions I think it is the time now and as I finish answering the questions I am going to go here and update and you will see that the new change will be here that's all for me alright question thank you doing great so we have a question from the chat room I want to make sure we cover OREC says is YAML build available for .NET framework builds now yes as you were able to see when you create here a new pipeline actually the default option is YAML not supported yet is that the build definition that I did here to export it to a YAML definition but I think that will be later but yes YAML will be supported any other oh that's so cool yeah that's cool it is the new version here you will see here that the new release will be triggered automatically there it is so this is truly one click deployment well I didn't click anything I just pushed the change and I should do the rest so we have got some folks that are in the chat room that are saying they really like this content they can't wait to see it on a replay so they can go out and check out videos on demand of course there will be video on demand available here on Twitch we are going to also cut this video put it together on our YouTube channel so folks can see that as well and there is our ASP.NET Core website that's cool great stuff cool awesome alright so MagicNet asks how did you disable the old releases link where you got the releases star link I am actually kind of excited to hear that answer too what do you stop this is that what you are saying does he have the releases star no I meant on the sidebar I think what he is asking is on the sidebar you see how you got the releases star tab when I look at that in my own I see releases with no star and then releases with a star do you know if that is something that is like a VSTS to Azure DevOps migration thing or do you have any insight as to why some of the C2 releases tabs yeah that might be the reason because I created this project from scratch so that's why you might be seeing something different because I think for you won't see that alright makes sense awesome presentation so where can we go to get some more information do you have some resources for us yep you can always find me on my blog or on twitter I publish a blog post every week so you can find me here here is my contact information and I will be happy to answer any questions that the audience have awesome and let's put up your information real quick there we go so there is your twitter links can connect with you and there is your blog up top great stuff I think we're I think we're good here thank you so much Christian we really appreciate you joining us here for .NET Conf this year this has been great cool thanks to you alrighty


Thank you all for attending this late afternoon session before the end of the day in a booth crawl. My name is Raymond De Jong. I'm very happy to present here about adopting network policies in highly secure environments. The agenda today is this is not a network policy 101. This is more like a talk how we see our customers dealing with adopting network policies in the in the field and how you can use, for example, Syllium, EVPF and Hubble, our Hubble UI and Hubble CLI, to basically observe traffic and adopt network policies in your classes effectively without blocking your applications. So I'll start with some strategies, tips and tricks and approaches to adopt network policies and then talk about Syllium features that matter for using that and looking at observability as a superpower to make sure that you're able to enforce security and observe flows to ensure your compliance. I've prepared a little demo so I hope the demo gods are with me so I can show a little example how you can use your Hubble, for example, to secure your workloads. My name is Raymond De Jong. I'm field CTO for EMEA at Isle of Valence. That means that we also work with a lot of customers both open source and our enterprise release who are adopting Syllium and EVPF in their environments to secure those environments as well. Can I see hands? How many of you know about Syllium? All quite about quite a lot. Okay, so how many of you know EVPF? Right, cool. And how many of you are already applying network policies in their environments? Okay, a little less hands. Okay, great. So that's the whole purpose of today to give you that tips. So Isle of Valence is the company behind Syllium and EVPF. We created Syllium. We open source Syllium. We're still contributing to the Syllium open source release. And we also maintain EVPF. I will talk about Syllium and EVPF a bit later. So let's start with having a bit of a talk about strategies for designing network policies. What we see is that a lot of companies struggle with adopting network policies. You want to avoid allowing everything. A lot of companies want to have a zero trust based approach. But in the meantime, you also do not want to block your application teams and you may want to make the onboarding of your application as easy as possible. But you also want to prevent application teams themselves to allow all traffic for their namespaces and going in and going out. So you need to have some constraints there put in in your system to avoid such a thing. You also want to, a lot of our companies also need to have compliance. They want to ensure and that all their flows are being enforced as such. So a default deny approach in practice is really hard to start with from the start. So there is no easy road for adopting network policies unfortunately. If you start with a zero trust, you most likely will run into issues with onboarding your applications and that will result in having adoption problems of your applications or friction with your application teams wanting to use your Kubernetes platform. So a better approach we try to use here is to focus on risk reduction. So that means that you need to define metrics for risk. You need to understand what's important for your environment, what kind of metrics you need to monitor and to apply your policies on and to also move to fine-grained security policies and focus on most sensitive namespaces and leverage network observability tools to move to more fine-grained serial network policies. And once the tooling and your policies flows are proven, you can repeat this across multiple namespaces and multiple platforms. So typically obviously application teams or multi-tenant platforms have one or multiple namespaces in a cluster or across clusters and have deployments which you need to secure. So it makes sense to have a focus on the namespace level. When we talk about network policies and securing those workloads, it's good to understand the four types of risk exposure. First of all, very obvious. If you expose a service to the internet, that's a potential risk, right? So you would like to secure and monitor that flows. Additionally, if you expose a service in a cluster, that can also be a risk for exploiting that service from external network resources. In a given cluster, by default everything is allowed. So that means that you have obviously wide blast radius you want to reduce. You also want to avoid data exfiltration for egress connectivity. So the goal is to reduce unused access for any access that creates exposure without actually being required. So that's also where the metrics are important. So we want to reduce the risk by reducing the wide blast radius. Again, your Kubernetes API may be exposed. Your namespaces are open by default. Any pod can reach any pod. So in any case, when a workload is exploited, that could lead to a huge risk for a wide blast radius. So our focus is to reduce that blast radius and isolate to start with from a namespace level. Also, with strong observability, you can match or see and observe any mismatches with your current applied policies. And what you want to minimize on that. So if you see a lot of drops, that can either be a risk in terms of an attack, but it can also be that something needs obviously some kind of access. And there are some examples, right? CubeDNS is a good example. You need access to QBDNS. Every namespace workloads need access to QBDNS. But a front service exposed through a low balancer is the only one needs to be exposed for on a port for 3, for example. But the actual service behind it, for example, RedisServer, doesn't necessarily need that. So avoiding that is a good best practice. And then you can also prioritize on the number of service you expose through either Ingress or Gateway API, because most likely those are services which are exposed on your network or even on the internet. And then also focus on services which are reachable within your cluster, across namespaces, and number of services with access to external resources, such as egress. Now there's also a risk if you do this approach of overfitting. And what we mean by that is that if you have a strong observability tool, you can potentially do a one-to-one translation for each flow to create a network policy. But what the result will be will be a very brittle network policy design, because when there is a little change in application or a new version of an application, that immediately means that a small network policy somewhere needs to be updated or created. And at scale, this will not be feasible. So our approach here is to start with an initial namespace policy and use global policies across your platform or even across clusters using cluster-wide network policies to define the card rails. So you can use, for example, cluster-wide network policies to secure for each given workload access to QtDNS to allow that service to be reached. Also, for example, Prometheus, that needs access to monitor your services. But on each namespace, you can only allow traffic within a given namespace and then use your observability tools to create flows, create rules, sorry, for specific egress or ingress connectivity. So when you use Hubble and Cilium, you can start with a default namespace policies, where you can observe traffic, and I will show that a bit in the demo, to inspect what is being reached out to egress and or ingress and secure that access. Then you are going to transition from this per namespace security with global policies as guard rails to more fine-grained policies. Obviously, focus on the most sensitive namespaces first and focus on the metrics you've put in, for example, using Grafana metrics to see where you have the most exposure, which services get hit the most, where is the most traffic flowing to those specific namespaces. For egress connectivity, maybe you want to narrow down specific FQDNs or specific ciders to allow access on a specific port. And for ingress, you want to expose connectivity for low balancer and only allow, for example, the ingress to create a given workload in your namespace. And then you will be able to move with global baselines again, which has already set, which set the global baselines for your cluster, but additional network policies per namespace for specific connectivity. So in this example, specific FQDNs with specific ports, only to be allowed access egress from that given namespace. Then use, for example, CICD pipelines, tools like Argo, Flux, your GitOps pipelines, at such to manage all those network policies. At scale, as a platform team, you cannot maintain all the network policies. So you want to delegate the creation of network policies to your application teams or your tenants. However, you would like to guardrails access to, for example, Qube API, Kubernetes API. But you also want to create cluster-wide network policies, which prevent any unwanted access. So you can prevent, for example, any outbound connectivity on port 22. However, obviously not on 4.4.3, because most likely some egress service need that access. However, you can use tools and automation and checks to automatically drop such PRs, which a given tenant may submit, to access of such a destination, and only allow specific FQDNs or specific IPs automatically. So what we see in practice as well is that, obviously, there's also this approval flow for given teams to approve a given policy. And we also see a lot of automation, which automatically checked for, example, CIDR blocks, which are definitely not approved to be allowed to access using a policy. Think also about resources in the cloud you want to protect from a given Kubernetes policy. So now I'm shifting to the part where I think Cilium is great to help achieving those goals using features which are specific with Cilium and EBPF. So for those who don't know what EBPF is, we like to say what JavaScript is to your browser. EBPF is to the kernel. That means that we make the kernel programmable in a very dynamic way, in a secure way, without changing the kernel. And this allows us to unlock a lot of features in terms of networking, security, and observability of which we talk about today. So think about when a pod or a process sends a packet, wants to open a port. These are kernel events we can inspect, we can secure based on the network policies we set. Cilium is built on EBPF. You don't have to be an EBPF expert to operate Cilium. Cilium abstracts this technology for you. So based on the settings you enable or disable, Cilium will be configured to do the awesomeness EBPF brings. And those are obviously in the space of networking, observability, and security. And what we're focusing on today is the network policies. The encryption part obviously is a huge important feature for enterprises. But also note, for example, egress gateway, which allows you to configure egress connectivity out of your cluster on specific IPs. For ingress, obviously we use also surface mesh. And this is not the topic for today, but that allows you to do, for example, path-based routing, MTLS, TLS decryption, for example, gateway API support as well. If we talk about security in Cilium, it's important to know that it's based on identity-based security. That means we're not tracking IPs. Instead, we assign a unique identity to a given workload. And that's based on the metadata you provide to this workload. So let's say we have a front-end service and a back-end service. They have metadata associated with those services. That unique set of labels will result in a unique identity. And we use EBPF to attach that identity to the data plane. And we use that identity to secure and observe traffic from and to this given service. And an identity is a cluster-wide property. So each node knows about this identity and can provide the metrics, visibility, security you need. Additionally, Cilium provides layer 7 security. So beyond the layer 3, layer 4 security, we also support layer 7 API-aware security, meaning that we can inspect and observe and secure specific API calls, for example, a specific method on a specific URL. And this goes beyond HTTP because we also support GRPC, Kafka, Cassandra, and other protocols for that inspection and security. How that works is using Cilium network policy. So this is a Cilium COD where you specify, for example, where to match this rule 2 and what labels it should allow from, so from endpoints. And then on a specific port, you can add additional rules in this example, HTTP rules to only allow a GET method, in this case, on the public URL. For egress connectivity, we also support DNS-aware Cilium network policies. This is super useful for cloud resources that you want to secure access to for those services because they change IP a lot. So if you look at S3 buckets, for example, if you have media content there stored and your workloads need to reach out to those, the underlying IPs will change a lot. So you wouldn't like to allow the whole CIDR block for those services, but instead, specifically allow an FQDN for that given service to be allowed egress connectivity to. I also mentioned the cluster wide network policies. And this is such an example. This will be applicable for every workload on your cluster. So in this case, it's an example where we want to allow access to Qt DNS and allow Qt DNS itself as well to use to do DNS request itself. So in this case, we have also used the entity world, which means any. We allow Qt DNS on port 53. But we also allow, for example, Prometheus access for all namespaces in this cluster and on a given port in this case. This is also how you can secure, for example, on a per namespace. Allowly. So if you want to template the default allow for traffic within a namespace, you can also leverage cluster wide network policies. If you have a multi cluster use case, you can create network policies with spans across multiple clusters. So using synium cluster mesh, you connect multiple clusters independent of their clouds. If you're run on prem on open shift or on Azure or or on GKE or both. This you create a unified psyllium data plane. And that means that you can create psyllium cluster network policies or psyllium network policies across cluster, which are cluster aware. So we understand the identity of each cluster and each cluster has read only access learning those identities from another cluster. And we can use again, those identities to secure and observe traffic across clusters. So what it means in this example, and I hope you can read it, the front end tries to reach out to a back end, which is in this case deployed high available across clusters. And using ebpf and this identity, we're able to secure and observe that traffic across clusters. That's done through synium network policies. So in this example, you can specifically allow access from a specific cluster to another cluster and deny and drop traffic from another cluster as well. So you can mix and match local cluster network policies with policies across clusters. And this is based on the cluster label, the cluster name, which is a unique identity in psyllium. And this is a simple example of such a network policy. In this case, we have a rebel based workloads where we want to apply this policy to and we allow ingress from the x-wing workload from cluster one on a specific board. So only from cluster one, that specific workload is allowed. Now, now having network policies and adopting network policies is extremely difficult without right observability. And therefore we have introduced obviously Hubble, which provides flow and visibility of your workloads across clusters. And this also enables you to do data operations on psyllium network policies. Obviously applications change and providing Hubble access to your teams allows them to learn what has changed and what flows they need to allow using network policies for the application to work. Hubble consists of three main components. The Hubble UI provides a namespace view of all the connections within a given namespace. It gives a view for namespace to namespace connectivity and also workloads in a given namespace if they access egress resources. We can see that if you enable DNS aware policies, we can also see the DNS requests, which I will show a bit later. And we can also see ingress connectivity. So traffic coming through, for example, an outside resource through a service through an ingress resource in your namespace. The CLI is a more powerful tool for advanced filtering, advanced troubleshooting. You can also output to JSON, which you then import in, for example, another tool, or to be able to export flows to other scene platforms. And Hubble metrics is everything about exporting these metrics, this flow data, layer seven data to Grafana, for example, using Prometheus. So you can create this metrics I mentioned before in Grafana dashboards for you to use. This is a quick screenshot. I will not spend too long here because I have a demo with this as well. But as you can see, it provides, in this case, a book info view. So I've deployed the big book info STO demo application. And I can see service to service communication. And this application is accessible in this example from the internet. So I can see ingress connectivity through our Syllium ingress into the namespace. And I can see the service to service communication, the ports being used, if it's dropped or allowed, and which protocol is being used. A great tool for helping you creating network policies is the network policy editor, which is reachable through editor.syllium.io. This gives you a view on a namespace level for both ingress and egress connections. And this is a visual tool to create network policies without understanding how to actually write the YAML from start. And you can write both Kubernetes network policies as well as Syllium network policies. And using the UI, you can allow or deny specific flows, which automatically creates this YAML you can download and apply on your cluster. And recently, we also released Grafana dashboards. So you can use access to Grafana marketplace, where you can find policy verdict metrics. And this is a great tool to monitor how many matches you have on flows in a given namespace or across a cluster. And this allows you to verify if you have created enough network policies to match all the flows and that you're fully secure. And also, if you have drops, you can obviously monitor that. And I will show that in the demo as well. Okay. That moves me to that. That introduces the demo. So let me set it up. I hope you can see in the back. Can you show hands if you can see the command line properly? Great. Thank you. So in this demo, I've deployed Hubble UI. So I've deployed a simple application for showing how you can transition from coarse grain to fine grain policies. And I also installed Grafana in my cluster. And this runs on GKE. And this is currently showing metrics for all namespaces. And I want to focus for this demo on the MyApp namespace. And as you can see, I only have matches on all. So that means that I have no, for this given namespace, I have no match of a specific network policy allowing layer 3, layer 4, or layer 7 network connectivity. And that's the goal for today to make sure we have matches across all flows. We're also able to monitor ingress. And below we can see what kind of services there are running and what kind of destinations and sources are being used. So let me move to Hubble. So this is a simple example. We have a client server connection. The client is talking to the server. You can see we have live flows appearing. We can see that it shows connectivity to the outside world to outside the namespace. And in this case, we can see watching the flows. It's actually accessing public IP addresses. We can see that the client is talking to the server on port 80. Currently, the flows are obviously allowed with this given namespace. And the goal is that we want to secure these connections between the net in within the namespace and egress to destinations on world. So what I do first is I'm going to apply a city of network policy on this network on this namespace. And the only thing I want to do is allow access to Qube DNS. And the goal here is that I want to learn what FQDNs this workload is reaching out to on the internet. So this is how it looks like. This is an example you can find our documentation as well. Let me quickly apply this file. So I'm doing Qube CDL apply file DNS YAML. So now this policy is created and Hubble should already, yeah, so it's really quick. This is live flows shows live actually the FQDNs it's trying to reach out. So now using Hubble UI and using the simple DNS policy, I learned that it's reaching out to ceiling.io and isovalent.com. And in this case, that's fine. And I can use this information to create a fine grained Celium network policy in my next steps to allow that specific connections to those destinations. And the next thing I want to focus on is on the client to serve a connectivity within my namespace. On the Grafana site, I can see that let me zoom in a bit on the five minutes. I can see already apply applying this network policy that I have flows matching because I'm intercepting this DNS queries from this given namespace. And we can see the purple bands created being created for showing that kind of flows egress. And those domains are also visible in my dashboards. And I have metrics how many flows are being identified. So let me now focus on the server components yet another prepared another network policy. So in this case, I want to allow only the client endpoint to reach to be able to connect to the server on port 80. So I've prepared this policy. And for sake of time and given this is port 80, let us assume that we're also want to allow HTTP. So this is a layer seven Celium network policy. And I want to inspect this HTTP traffic and allow this HTTP traffic. So save this and do QPCTL apply server. Now in Hubble, we already see that on the surface side, if I zoom in, I can see that I also now get HTTP context. I've applied this policy. I allow I allowed all HTTP methods and URLs, but now I can actually see what kind of requests the client is doing. I can use this information to make it even more secure if I wish to do so. So in this case, it's doing gaff methods on this base URL. And in this case, it's fine. Next thing I want to do is secure the client. Before I do that, we can also see on the egress side, we have more matches on the flows. And on ingress side, nothing has really changed as such. Next step is the client. So I use again, the information from the Hubble UI. It's reaching out to the server on port 80. So let's allow that. And we also learned in my previous step that it needs to access Celium.io and isovalent.com on port 443. Also note that I'm adding this server matching labels and obviously on port 80. Save this. Apply it. And then we should see. We don't see a lot of change in Hubble because we're already allowed that connection. We do know that it's allowed to reach Celium.io and isovalent.com. We do have already the server policy applied. But on the metric side, we should see that we have now also ingress policy matches. And we should also see egress policy being matched. That means that I expect that this egress policy verdict rates will show all green for matching traffic. It's already decreasing. So now I've basically secured outbound connectivity, ingress from the server component, only allowing access to the server on port 80 with HTTP. So now I'm safe to also delete the default, allow traffic policy for communication for that given namespace. So let me delete this. Obviously, this shouldn't change anything here because we have created the right network policies. And on the policy verdicts, we can now confirm both ingress and egress using this dashboard that all traffic are matched on this side and on this side. So what happens if an application changes or reintroducing a new namespace and an application in that new namespace needs to access this given workload? So let's have a look there what happens then. I need to go back to another directory. So I'm introducing another app. Not in the right directory. Bear with me. So this is just another namespace with a simple another client reaching out to this given workloads. Now let's have a look what happens. So on Hubble, we should at some point, once this workload is created, we should see drops because we're not allowing cross namespace workloads. So here you can see this another app is being created in an other app, another app namespace. And we can see here little red lines traffic is dropped. And we could also zoom in on the server components. And we should yeah, we already see some drops here. Right. So we're seeing confirmation that we have secured this workload. This other app is not allowed to reach this workload. And the policy verdicts also confirm that. So I have also metrics for this drops. So we need to do something about this. Let us assume that this is allowed. That means that we need to change in this case the server synium network policy. And let us assume that we already know it's HTTP port 80. So we're allowing that as well. So we're allowing layer seven access. And we select the specific namespace and obviously the app. So now we're going to the policies directory. I'm applying the server YAML. I just updated. So that's now configured. That would should result in hub UI also confirming that. Yes. Now we can see another app is allowed to connect on port 80 with HTTP to the server components. And the metrics confirm that as well because at some point we should see the verdicts drop and the traffic being allowed. I've one minute left. Final slide to conclude this session. You can try this out yourself. We have excellent labs hands on labs created on our website is of 80.com forward slash labs for both open source and senior enterprise to try out network policies hub UI and to learn hands on yourself how you can adopt network policies. There are also great examples of such cases using our studio.io website. There are some nice star wars based examples across clusters as well. You can try out if you want to know more about ebpf. I recommend to visit ebpf.io and visit our stand for more information. Maybe we have some ebooks or books left about this topic as well. We have a signing session tomorrow with Natalia. She wrote a book about securing using ebpf both on runtime and network layers access and processes. I'm open for any questions. Are there any questions? You can use the mic here. Good. Thanks.


As a factual matter, the United States, those of you who worry about an American invasion in any of your countries should sleep well, because right now the United States, both the Democrats and the Republicans, are isolationists. I'm sorry? Are using drones. They don't send their people anymore. Well, I am not.  Are you a pacifist? Yeah. Well, I'm not. And many people are not, and there are good moral reasons not to be a pacifist. We can disagree about that, but the fact that the United States uses drones from the standpoint of the morality of war, perhaps you think war has no morality, but we know that philosophically and theologically, there is such a thing as a just war, and people in this continent are living off the fruits of a just war. Is Vietnam a just war? No, of course not. No. Was Iraq a just war? No, it was not. But no, but I wish, World War II certainly, I prayed every night that the United States would send 5,000 troops into Syria in 2012 and 13 and 14 to stop that madman from systematic rape and genocide and the murder of children. And in 1972, George McGovern, the greatest dove who ever lived, suggested that an international be forced to be raised to stop Paul Pot's genocide in Cambodia. There are moral emergencies. There are madmen with power in this world who are prepared to do repulsive things to men, women and children. And we can either decide that we have no right to intervene or violate their sovereignty or that we are pacifists, in which case we may as well concede that we are prepared to see these evils proceed without any obstacle. But if we agree that we are not prepared to see them proceed without any obstacle, then we are back in the discussion of who uses what kind of force when. And that is a very, very fundamental thing. There is evil in the world. Do you understand who created ISIS or who sustained it? Oh, I have a different, I understand how you understand who created ISIS. But I think it's a much more complicated picture than that. I do not believe that everything that anybody in the world does is either a director or indirect response to the United States. I think that people in South Asia and in the Middle East have agency and cultures and traditions and interests, and I think they act upon their own perceptions and representations of their situation. It is a very complicated world. It really is not the case that directly or indirectly everything bad that happens can be traced back to the Pentagon.


by 4 to the 80, start to creep up just a little bit, second lane, go quarter, go quarter, clear by half, by half, coming back inside, get a fill, in by 21, now top of 3, top of 3, nice in line with you, fill inside, 1 inside, clear by half, bottom lane.