CNCF [Cloud Native Computing Foundation]

Lightning Talk: Using Keycloak Authorization Service for Kubernetes Service-to-Service… H. Özkan

Duration: 15:44 1699 transcript words EN summary

Video summary

The presentation introduces a streamlined approach to securing service-to-service communication within Kubernetes by leveraging Keycloak not just as an identity provider, but as a central policy decision point for authorization. Traditionally, organizations rely on Keycloak for user authentication and token issuance, but this talk proposes extending its capabilities to handle internal microservice interactions without requiring modifications to the application code or external policy engines like OPA. The core concept involves using Keycloak's built-in mechanisms to evaluate permissions based on resource scopes, effectively making it the sole authority for granting access while eliminating the need to learn new complex policy languages. To implement this architecture efficiently, the speaker utilizes Istio Ambient as the policy enforcement point, which intercepts traffic at the namespace level rather than requiring individual sidecar deployments per pod. A custom plugin developed in Rust using WebAssembly is integrated into the Istio Waypoint to operate at HTTP layer seven, mapping incoming requests and their scopes directly to Keycloak permissions. When a service attempts an action, such as retrieving or posting an order, the Waypoint forwards the request to Keycloak via a UMA ticket grant flow. Keycloak then processes the request in a single round trip, returning either an approved token with the specific scope or a denial response, allowing the system to instantly allow or reject traffic based on pre-defined policies. The demonstration highlights the practical performance and security benefits of this setup, showing that authorization decisions incur minimal latency, dropping to around two milliseconds for successful requests. The system robustly handles various failure scenarios, such as missing tokens which result in a 401 unauthorized error, or direct attempts to bypass the mesh by accessing pod IPs directly, which are blocked by Istio network policies. Furthermore, the architecture addresses potential single points of failure by recommending a high-availability setup for Keycloak, ensuring that even if the authorization service encounters issues, the overall system design remains resilient and secure against unauthorized access attempts. In conclusion, this solution offers a secret-free method for managing service identities using UMA, simplifying credential management compared to traditional client secret approaches. The project is open-source and available on GitHub, inviting the community to clone, run, and contribute to the plugin which supports both UMA and CPAF flows. By centralizing authorization logic within Keycloak and enforcing it through Istio Ambient, organizations can achieve a secure, low-latency, and maintainable security model for their Kubernetes environments without the overhead of managing separate policy engines or modifying application logic.

Read the full video transcript

Hello. Hello, everyone. Konnichiwa. So, excited to join here in Keycloak Java Keycloak on Java, sorry. Hi, community. This is Halil from Team Eight. Today, I want to share By the way, can you hear me well? Voice is good? Good. Good. Good. Today, I want to share an idea. And it's very simple idea, to be honest. You know, we already use Keycloak for identity provider, user authentication, issuing token. Yes, it works well. Most of the people all the organizations or many organizations already use this way. But, what about using Keycloak also for authorization, service-to-service communication, and even in the Kubernetes, and without touching applications? How it works? Yes, it works. Also, we don't need any policy engine like Opa. Yes, uh in this uh I said, yes, we already know Keycloak, but let's try to uh think that the Keycloak will be making all the decisions as a policy decision point in this model. And also, we need an policy enforcement point. And to make it easier in the Kubernetes network, so, we just focused on Istio. We already used all the models. By the way, anyone using Istio now? One, two, three, four. Four. Good. Uh you know, Istio is a good service mesh solution. It provides two architecture. The one is side car model, the other one is ambient model. Side car is also very popular. We already used since last 5 years. But now there is a good news from Istio team. Which is called ambient. So, you don't have to deploy side cars per pod. Instead, just think about deploying per name space. So, that's more economic and more easy, right? And in this model, we used Istio ambient as a policy enforcement point. So, it just intercepts the traffic and asks to the Keycloak, "Hey, here is the request, HTTP headers, body, and so on." And Keycloak maps this request as a resource scope and then return back the evaluated permission. So, this is the simple idea. And again, no new policy we need. So, you should learn you should not learn anything. Just focus on Keycloak for authorization including its own policy engine. It's simple. Let's make the model concrete. So, that's why we have a new end point. It's an orders end point. And we have two scopes, get and post, very usual classical one, right? And we developed a plugin. This plugin just intercepts the traffic at at the HTTP level seven. And maps the requested resource with the scope to the Keycloak permission. And bind it with the policy. And we have one policy for all the readers. And we have one permission for the scope get. So, also another interesting point is, you know, there are several ways in the Keycloak, and one is the token exchange, another one is the UMA, UMA. You know, user managed access. This the ticket grant flow also works well. So, in one round trip, so, it helps us to evaluate the permission and return us a requested scope token. So, in one round trip, it's it's really good. So, in the demo also we will see the latencies, so, this plugin just makes this request passed to the Keycloak, and Keycloak makes all the decision and returns back the evaluated permission including the scope token. That's it. Yes, this is the part we are contributing back to the community, so we created a plugin. Uh this is developed in Rust using WebAssembly. And you can use this plugin. At the end of the demo, I will sharing the GitHub links. You can just download it, run it, clone it, or change it. And whenever you just plugin this plugin, plug this plugin to the Istio, as I said, it will be just intercepting the traffic and just making the UMA ticket grant flow to the Keycloak and returning back. And it will be just either um forwarding traffic to the service or rejecting back. And plus also it emits all the open telemetry instrumentation data, so you can also follow track whatever you want. Reads the HTTP traffic including headers, body, have ask to the key cloak who is which is the PDP, makes the decision and enforcing the decision, allow or deny. Yes, we have two ways. Also, we we will be sharing all the links at the end of the demo. The first one is using the UMA not to token exchange, as said, since the one trip achievement. And the other one is using the CPAF, the famous one today, huh? Also, but today we will be just focusing on the first one. The party UMA version. Uh in the UMA, you know, the subject is the user, but for the service identity using the CPAF, we just utilize CPAF to to focus on subject if it's the service. But on the UMA, also there isn't another thing, it's a secret free, so nothing you have to keep and store and But for the service identity, you need to provide credentials, client credentials, or for the PEP to PDP contract. Okay, before proceeding to the demo, let's try to understand how it works how it will work at all. We just need an equity notice. You just need to install is to That's it. And of course you need to create some policies in the key clock. And whenever the user tries to access get using a get method on the orders method, we should receive a success. But whenever the user tries to make a post, it will fail. And whenever you see any issue with the no token, of course, it will say 101 or 401. Or what about hacking the system? If you want to hack the system by how? By just making an access to the portal IP directly, what shall we do? The answer is thanks to the is to it just resets the traffic. So, we have no idea. Or what happened if the key clock is down? However, it's not very gracefully shutting down. This time Yes, we should say that uncertainty is network means I believe a lot. So, that should stop everything. Yes, it's a kind of single point of failure, that's why you have to make the all the installation with the key clock in the HA architecture, right? Okay. Let's try to make a demo. This time it works. This is a very fancy dashboard for this demo. Okay, and it will help us now. First of all, let me try to tell you what is here. By the way, can you see it exactly good? Let me make it bigger. Is it good? Okay. So, we have a usual user. Okay. And the user wants to invoke this service, service A. And this service A should invoke somehow service B for the some reason. And here is the Istio waypoint. By the way, waypoint is responsible for layer seven. But for the level four protection, also it has the Z-tunnel module. It has two two models. Two modules, sorry, in this So, let's grant a token using the password credential. Where is my screen? Uh-huh, it works. Oh, okay. So, we have a good start. So, the external user just got a new JWT token using the password grants. And now, let the user make a get request on the order endpoint. Wow. What's happening there? Okay. The user hit the service A, service A tried to reach access to the service B, and Way point grabbed the traffic, intercepted the traffic, asked Keycloak, and Keycloak said, "Yes, yes, it's possible. You are allowed." And by the way, we also collect through the auto collector all the telemetry data from Keycloak, from service, from the plugin, from the Istio itself. So, that's why here you see this latency for the BDP, I mean the Keycloak. And in this case, it's 8.8. End to end, it works well, right? And let's try to do the same again. Let's see if the latency will be reducing. Yes, now it's better. Let's do one more last time. Yes, around 2 milliseconds. It's good, right? Okay, let's try to make a deny operation. Okay, the user is not allowed to make a post on the orders endpoint. Let's do it now. Click the deny button. Way point ask Keycloak. Keycloak says, "No, man, you are not allowed." 403. It's not good. And if you check the latency now, it's 3.3 milliseconds. Let's do this one more. Yes. It's almost same. Okay, if we have no token, let's try to hack the system. If the user sends a request without any token, what will happen? As you see here, the plugin in the Way point in the Istio Way point just rejects the request back to the user. The user has no token. That's why it should receive 401 unauthorized. And if I want to hack the system, I'm a Kubernetes guru. I created a port forwarding to the direct the pod IP pod IP address. Let's see what will happen. Okay, so using a direct port forwarding, I just want to send a request to the service B from service A container, and it's blocked. The Istio that tunnel blocked the traffic. Since we already created a network policy using Istio. So, this doesn't allow direct access. Always the traffic should go through the waypoint. So, now we have no gap. Uh maybe I should do this one more if we have time. No. Let's shut down the Keycloak. It's the last part. The last part. No, it's running. No, it's done. Okay, let's try to make a new call. Just try to log in. The user tries to log in. Keycloak is off now. And the service is unavailable. Okay? So, let's go back to the presentation. The time is over. Thank you so much. So, just try to clone, run, make the contributions, change however you want. Use the contribution from Kemet. So, you can either use the Yuma version or the speaker version. I would like to ask for if you have any question.