 A very good morning, good afternoon and good evening to all of you from wherever you are joining. Welcome to this webinar where we would be talking about securing requests with Key Cloak and Istio. So we would be diving into the world of Kubernetes security. Before we do that, a quick round of introductions. I'm Atul Priya Sharma. I am a CNCF ambassador and I also work as a senior developer advocate at InfraCloud where I deal in cloud native technologies like Kubernetes, Istio, and have been exploring observability of late as well. Outside of work, I am a 4D and love doing road trips. Good morning, good afternoon, good evening. I am Sherpas Pratap. I'm working as a site-level engineer at InfraCloud. I actually started using cloud native service back and now I help our clients to build robust, secure, and reliable infrastructure using cloud native technologies. Quickly getting into the agenda of what we plan to cover in this webinar. So we would start by giving an overview of the various security options in Kubernetes. We'll then dive into Istio and we'll see how authentication and authorization works when it. We'll also look at request-level authentication and authorization. Quick look at JWT tokens and finally into the demo. So to start with, we know that Kubernetes has become the operating system of the cloud and with the complexities that our application and infrastructure have, it's very important to have a robust security measure in place. So we'll start by discussing some of the existing security features that Kubernetes has. So Airbag basically helps us control who can access and perform actions without accessing your Kubernetes clusters. So you can think of them as bouncers at an exclusive club. So it allows you to define fine-grained permissions for user groups and accounts. This is one of the very popular ways for securing access to your clusters. Next one we would like to discuss about is pod admission policy. You can think of it as your vigilance security guard outside your building. And so when a pod is created, the policy kicks in and validates the configuration and ensures that only authorized folks are allowed access to your pods. And lastly and most important is the network policies. And if you are dealing with networks within Kubernetes, you would have come across network policies. These are basically like virtual fences that safeguard your network. So we can create logical boundaries that allow only authorized communication. These three are relatively the basic options, yet important options that Kubernetes provides out of the box. However, there are a few shortcomings of these particular native options. So especially looking at it from a point of view of network policies. So the first one is that network policies focuses only on controlling the traffic. And it does not provide a mechanism to force your internal traffic going through a common gateway. Apart from this, it also doesn't provide any feature to tackle with DLS related configuration. So if you are going to handle anything related to SSL certificate management and encryption, these options don't quite provide these features out of the box. So that's where we need some tool that can help us deal with all of this. And that is where Service Mesh comes in. Service Mesh such as Istio or Linkerty, it provides a dedicated infrastructure layer specifically designed to handle secure communication. So in a typical microservices architecture, you know that services communicate with each other extensively. And it's very important to ensure that all the communication that is happening is authenticated and secure. So apart from the regular features like traffic shaping, load management, as well as traffic routing, most of the service meshes also come with security features. Some of them include native support for MTLS and JWT authentication, which is basically, you can offload the authentication from your application, from your cluster to Istio or Linkerty, whatever service mesh that you're using. It also gives you an observability layer so you can control and have a visibility over the network traffic. So in a way, it also helps you secure and monitor traffic within your network. And lastly, it also gives you some fine grain access control over your network and the requests that are coming in. So this was pretty much about what Service Mesh can do when it comes to security. We will now look at how Istio can help us in this regard. So let's see Istio's authentication and authorization. How Istio provides the, out of the box authentication and authorization for your services in your Kubernetes cluster. So basically Istio provides lots of authentication. One is peer authentication and another is a request authentication. So peer authentication allows, like define how traffic is getting done to your workloads in your mesh. That means like Istio, peer authentication controls the mutual TLS traffic between your services in your mesh actually. The request authentication policy allows you to define the mode of MTLS which you are going to be used in your mesh actually. So there are three types of MTLS modes actually. One is permissive, one other is strict and the last one is disabled. So by default the mode is permissive. That means the client is sending a request to a server service and that client service don't have any certificate with it. Then it will allow the, basically it will allow plain as well as MTLS traffic. So that is what we can control through the peer authentication and request authentication used for the end user authentication. Like whenever a end user make a request to your services with any credential attached to it. So Istio request authentication is responsible for validating those credential. Most of the case Istio only supports the JSON web documents which we abbreviated as JWT. So request authentication verifies the attached JWT to your request and decide like whether the request identity is authenticated or not. And when the request get authenticated it forwarded it for the authorization. So next part of this process is authorization. So Istio provides authorization. It's a simple of the CRD custom resource authorization policy and lets us control the workload to workload and a work end user to workload traffic. So we can define multiple policies for our services in our mesh and control like how our services can authorize the end user or the service which is communicating from the same cluster. And there are basically three types of action which we can perform using authorization that allow, deny and we can provide the custom actions as well. By default the action is allowed. So whenever we create any authorization policy in our own mesh so without any action so by default get created with the allow action. It is recommended to start with all deny in your cluster and start creating some allow policies for authorizing the request coming from outside your cluster outside your mesh or the traffic coming from the same mesh or we can use authorization policies in multi cluster setup as well because Istio works very well with the setting up a multiple cluster. In this diagram we can clearly see like how traffic flows when we introduce a Istio service mesh in our cluster. If you see the traffic is like the traffic between services is MTLS like if you see the green lines that showing traffic is going from one service A to service B is MTLS and it's secured and the traffic from end user to your services coming through the interest gateway and the JWT with the JWT plus from interest gateway to your backend service is again MTLS. So end to end your application would be secure with MTLS and proper authentication and authorization mechanism. So let us get into the request level authentication and authorization. Before we dive in it's important to understand why something of this sort is actually needed within your cluster. So request level authentication in Kubernetes cluster serves multiple purpose. It allows users to access data securely. It grants programmatic access for various applications and facilitates reliable communication between various services. So what you see here are different use cases that we have listed where request level authentication might be required rather is required. So it basically is required to allow users of your application to access data on your server through a browser or over a mobile phone app. It also is required to give your end users both people and programs programmatic access to data managed by our application which can be through means of APIs or some end points. And lastly to let other services that make up your application's infrastructure communicate with each other. So these are some scenarios where request level authentication is required. And before we deep dive into the demo and the crux of today's webinar, let us quickly go through what JWT is. So JSON WebToken is an open standard that defines compact and self-contained way of transmitting information between parties as a JSON object. And it is a very popular user authentication standard as well. So this token is made up of essentially three components. You have a header, you have a payload, and you have a signature. So in this diagram is a basic structure of a JSON WebToken. So you can see the header which defines the type of algorithm and the type of token. So here you can see the algorithm type is HS246 and type is JWT. The payload essentially has the meat of the token. So things like the name, the issuer, what's the role, the issuance time. These are the things which we define in the payload. And lastly is the signature, where basically we can use a combination of our public and private key to sign the entire token. So the JWT token is basically consisting of these three particular components. And in today's webinar, that would be the crux of the demo that we have. Yeah, so STO allows us to validate JWT tokens using the request authentication, which is a custom resource, which we will see how we can get the request authentication in the demo. So request authentication will validate whatever the access token we will attach to a request while making API calls to our applications API endpoints and validate it with a key clock, because we will be using key clock as our authentication provider in this demo. And once that JWT get authenticated, it will get passed to the authorization policy. An authorization policy verifies whether it is the authenticated identity or not. If it is authenticated identity, then it will allow us to access the API. Otherwise, we will get an RBAC access denied error. And as you can see in this diagram, it is the high level of work, like how our application workflow will look like. So we will make the API call to our working for application with the JSON web token, which we will generate from key clock and we pass like it as an authorization bearer. And that request will go through the request authentication and authorization policy. And if all the things identify that JWT, which we have attached is valid, then we will get a response like a 200 response. Otherwise, we will get a 403 RBAC access denied. So let's see how this actually will look like in the demo. So let's get started with today's demo. And for today's demo, I will be using a local client cluster with the metal LB installed on it, which will allow us to create a load balancer service because we would need a load balancer for SKU in Gray Skateway and key clock service. I have deployed one simple application, which is a book in for application. That application exposes to 8.14, adding a book and one for outweaving the book, which we have already added into the database. So this tool, like this is the application method and this is the database, which we're going to store the book information. I have already set up a SKU on this local cluster, set up with a demo profile and installing a SKU is fairly a simple step. You can follow the official documentation of the SKU, how it can get started with SKU. And I have also installed the key clock locally in this cluster. So setting up a key clock on Kubernetes is also simple, you can follow the get started with Kubernetes right on key clock official documentation. So let's see how our application actually look like. So let me first make an API call to my get, I'll first extract the IPs of key clock and SKU gateway because we would need it more frequently in this demo. So I have to just let us make an API call to get the API endpoint and see what we get. So you see, we got the empty array, means there is no books added. So let us add one sample book to the database because if we see this, means it's not added. Let us check by making a good book. Now we can see we have added one. Yeah, but in real world, you may have your application exposing the API which is allowing users to store data into the database and you don't want, anyone can access those endpoints. It should be accessed by the authorized person. So let's say in our application example, we have to restrict our ad book API. In this case, in this way, only the authenticated user can only be able to add a book and the get book API will be available for public viewing all the books from the database. Let's see how SKU help us to do that with the developer. Any authentication provider. In this case, we are using key clock. So let's first set up a key clock. I have already installed the key clock. So let me, let me craft the IP of key clock service load balancer when key clock you want. When login as a admin, so in key clock, you can, there is a very good documentation of key clock in general. Go and read about how key clock works. Other features key clock provides like O2.0 or SSO or SAML. There are lots of features which we can provide. And in key clock, everything comes under a RIA. So there is a master RIA by default. We have, we will create a new RIA. So let me create a new RIA. I'll give you the name as a studio. I'll keep it simple for the sake of this demo. Then we have to create a client. We will create an open ID connect client which will allow us to request a JWT and generate a JWT. So the client type would be open ID collect. I'll give the client ID again as a studio. So I have to keep it fairly simple actually. So like next we don't have to change anything here. Anything here, yeah, then we are done with creating a client. So now create a user. So we would use this user to generate access to open and make a API request to our application. So I'll create a user as a broker admin. So this is a fairly simple step because for the sake of demo we are taking it simple, but you can explore what all things you can do with the key clock. So I have here, let's deal with this user. Let's set a password for this user. Let me set it as a password for this user. Again, don't use such a password. So now we are done with key clock setup actually. That's all we have created a real in that real. We have created a client and we have created a user. So let's see if we are able to generate a token or not. All the tokens usually end point to call when we want to generate a token. So here we have given the client ideas to the user name which we have created and the password and the client type. Here we are able to generate a token and we will use this access token to make an API request to our books application. So let's see how this will look like in action. Yeah, so for that first we have to create a serious request authentication to validate the access token which will attach to our request. So let's see how this authentication policy will look like. It is fairly simple. Here we have just created a match rule to where to apply this authentication policy. So here we are saying like apply this authentication policy for all the ports which are running with the label looking for and we have given the JWQ rules. So here we have given the issuer from where we are generating JWQs and here we are using this JWQs URI in the thing that Jason Webkey said URI which export its public key on this URI and Istio will go there and verify as we discussed in slides, Istio will verify the JWQs signature over this URI. So it is fairly simple. You will find more information about request authentication on Istio's official documentation, how all this works so you can go and check out that. Now let's apply this authentication policy, request authentication policy. So now authentication, request authentication policy is created. Now let's try to add a new book. This time we should not be able to add a new book because we have created the request authentication. But that is not a case here. We are able to add a new book and that's because we don't, we have to use authorization policies to restrict access to authenticated request only. We have authenticated that request but we have not restricted the access that only the authenticated request only able to access that API which is ad book in our business. So let's see, we have authorization policy as well. So this series authorization policy. So as we discussed, we have two endpoints. One is gate book and another is ad book. So gate book would be publicly available. So we have added only two. If you see there is no from here. And for the ad book, we have a from rule as well. So that from rule defines that the request is coming from the authenticated identity. And only it will allow. So here we are using star but you can find credit if you have multiple JWT issuer for the multiple endpoints. You can use that combination of issuer and the subject which you will get into the JWT payload. So as we showed in a slide, there are three parts of JWT, the header, the payload and the signature. So in a payload, we will get who is the issuer of that JWT and what is the subject. So you can use a combination of issuer and subject to find credit your access from. So here, after the sake of this demo, I'm using a star. So let's see how let's apply this authorization policy. And let's see what happens after. So the authorization policy is created. Now let's try to add a new book. Okay. This application don't allow us to add a similar book but this authentication policy is working. We should get our bank access tonight. We are not able to add a book now. Let's see if we are able to list the books or not. And yes, we are able to list books because we are not able to add because we have a restricted access to our ad book API. Now let's let me clear this. Now let's generate a JSON web token and use that token we are able to. Let me store this token into variable and access token variable. And now I'll use that access token. And here we are able to add a book using access token. We see the new book is added. Yeah, so it's fairly simple actually adding authentication authorization for your application. But it may get difficult if you have multiple endpoints, multiple authentication providers So in that case, you have to be more careful. So that is the end of our demo today. So that was a wonderful demo by Shevaz. We saw how we can use KeyClub to generate JWT tokens and then authenticate our request using STO's request authentication. So to sum it up, proper authentication and authorization are essential for securing any application that you might have. So Kubernetes native security solutions are not enough for a production grade security. So you might have to, you know, mix and match a couple of tools to create your custom security solution. And STO provides a seamless solution for controlling access and simplifies request table authentication and authorization as we saw in the demo. And it's fairly easy to use an external authentication mechanism like KeyClub which can help offload authentication from STO as well. So this approach makes the system more robust and secured. So that's pretty much it for the webinar. We would like to thank you for joining in. And we hope that the webinar was insightful and you took away something new from this webinar. You can reach out to us for any queries and any further questions. So thank you so much and have a wonderful day.