Sovereign Identities for Your Cloud Native Architecture... Alexander Schwartz & Sebastian Łaskawiec

This talk discusses implementing sovereign identities in a cloud-native architecture using Keycloak. The speakers, Alexander Schwarz and Sebastian Wascavis, explore the challenges of achieving single sign-on and securing credentials in a Kubernetes environment. They explain how Keycloak handles identities, integrates with OpenID Connect, and issues short-lived tokens for resource access. Recent updates to Keycloak include features like standard token exchange, user lifecycle management, and fine-grained admin permissions, all designed to enhance security and user experience in identity management. The session includes a live demo showing various authentication flows, including using client assertions instead of client secrets, and how to set up these integrations effectively.

them in. All right. So, it's uh about time that we start sovereign identities uh for your cloud native architecture with Keycloak. Welcome to this talk here at CubeCon. My name is Alexander Schwarz. I'm one of the key maintainers. >> My name is Sebastian Wascavis. I work for Defense Unicorns. >> All right. And let's get well deep into um Kubernetes infrastructure and keycloak. So in the end it's

all about this well epic quest of how to do single sign on correctly. You want to have one identity and you want to delegate resource access to selected services. And the thing that we use nowadays is mostly open ID connect. We want to have or credentials. You want to keep them secure. And when you then have a like your single sign on service as keylog at some

place, uh it will take care of those credentials and then issue shortlived tokens. And well digital sovereignty starts and ends when you well when you then host things for your own. So when someone else can pull the plug to your identity system, you're probably not as sovereign as you want to be. Also, um when it comes to road map and adding features, um with an opensource project

like keycloak, you can probably steer the road map a bit. All right, so about that a little short introduction to keycloak. So you have users with some devices. You have keycloak and what you need to do for that you download a container um start it up and connect it to the database and then you have services. Um the users login with their um be it username, password,

pass keys whatever with keycloak. Um then they get tokens you they use these tokens to access the services and once they these services can then either check these tokens by themselves uh or they can um yeah verify the token with keycloak so we can they can have a call back and introspect the token with open ID connect they can maybe there are even more things that are

not in the token that can be retrieved from such an endpoint when we use lightweight tokens here but that's another story. Then you have like a very sovereign setup with your identities running locally. But then identity is also like an integration topic. Um you can integrate keycloak with it provides s and open money connect. You can integrate with other s and open money connect providers. You can

also run in integrate with an LDub if you want to if you're an enterprise context. So in the end there are lots of connections uh happening and when you run it in your infrastructure you need to manage it uh with some kind. This is how well keylog first contact usually looks like. You have a signin page you put in some credentials username or email or password. Um

when you then enable more and more features you can um have it ask for pass keys. You can have a second factor in there. You can have user self registration. you forgot your passwords. All of that is in Looking back at the last year, what was then new? We added something called standard token exchange. Um, you basically can make sure that every time you send an a

token to an application that it has the right audience and the right scopes, hopefully very narrowly scoped, only a single audience in the token. Standard token exchange is the key to that. JWT authorization grants when you then uh authenticate a user in one place and then want to have that user access um applications in another place um across these trust boundaries uh that you can establish. We

did a lot of around authenticating users and last year you saw that 2FA recovery codes were fully supported pass keys was fully supported uh all the best practices of open connect encapsulated in FAB 2.0 depot are there and fully supported. Uh we have new guides about MCP if you want to integrate key log with your AI infrastructure thanks to Takashi the maintainer who's also in the room

here today. Um and workflows. So if you want to have some user life cycle management uh this is still in the works in the release that was published in January but in the release that is upcoming for end of March we will have it fully supported so you can automate things when new users join when user have have not logged in for maybe like 30 days or

90 days that you deactivate them all this life cycle management will be covered by workflows. If you then are an infrastructure person and want to integrate things and um there are some automation well principles around key that you can leverage something called fine grained admin permissions where you can delegate resource administration to entity other well people. So for example when there's a specific client you can delegate

administrating this client to a specific group of people who can then administer it. the same for users and groups. So that's now also fully supported. Um, a lot of automatically encrypted cluster intercluster communication, split brain detection, rolling updates, it's in there and it's get getting even better with the March update. uh when it comes to at least the patch updates that you can really roll them out

um seamlessly and federated client authentication that's also the focus of today's talk where will you will have less friction in managing all the credentials for the clients that you're running in your application because you can leverage not only like username password for a client but also leveraging existing tokens and we will we will hear more about that in the talk today. When you then run an IDP

in your infrastructure, you want to have great observability because when something is broken, you want to figure out why this is the case. And we now have very uh complete integrated open telemetry support uh for traces. So you can hunt errors and latencies. Basically, you can see when we well, if it's not DNS, it's LDUB usually when it comes to IDP. So you can have all the

calls traced to the LDUB and see what's going on there. if there's an error message if there's a specific query. Um logs um originally we put them on the console and the file on sys log but with the general release we added also support for logs the same for support for metrics that was also in the January release um and and yeah and dashboards they also been

around since last year. Currently we ship some Graphana dashboards that then capture a single pane of glass for your service level objectives around key so that you can measure like how good is my performance around logging in. Just one diagram about um how this tracing could look like. So you really see an LDUB operation here with all the filters applied in the search scope and how it's

was its timing and everything. So that's just a very brief look into that how that could look like. Well, and well, client and users need credentials and we don't and handing out credentials is expensive. Uh, rotating credentials is expensive. Um, and that's why we have now this lots of things around trust and federation built into keylog in 26.5 and 26.6. We don't reuse credentials, but we reuse

tokens obviously because they're shortlived. um this JWT authorization grant that I talked about earlier in one I would say IDP scope maybe a key cloak maybe something else you a user or an application gets a JWT authorization ground and then it sends it to keycloak keyclo will issue an access token and then you can use due to that trust boundary u between the two um sites or

organizations whatever it is in the end you can then login a user in another place um with their tokens in the end. When you want to do that for non-human identities, you can leverage uh Spiffy here where um your infrastructure provisions these tokens to all your applications and then your applications can use that as client credentials and then this is like infrastructure agnostic. Um it's all working

working fine. We're just waiting there's an RFC to to be finalized. Um, so that's why we keep it in preview for now, but it's working very very well. I believe a lot of people in this room might be using Kubernetes. So, um, if you're running on Kubernetes, there's something called a service account token that you can leverage. Um, so you don't need to roll out or if

you trust anyway, why not trust service account tokens and use that to authenticate to to key. Um, so in the end, it's all about issuers, signatures, and who we trust. And the good thing is we now see it live in action. Heading over to you. >> Yep. So during today's demo we'll focus on confidential clients which means client needs to authenticate in keycloak in order to get

a token. And we'll focus on three use cases. First we'll have a look at the old way of doing this. So we'll have the client ID and client secret. Uh that's a very wellestablished uh thing in our uh in our industry. But now we have better way to do it. and we'll have a look at this. So we'll have a look at uh client assertions that do

not require any passwords nor secrets and first and the third case we'll have a look at are the client credentials. So we'll be authenticating one machine to another. Um so let's have a look at the demo. So for today we prepared a very small demo application. Um it's very light. I'm not sure if you can see it. Um but uh the application is deployed in the same

cube cluster as keycloak. So first um we'll this is a typical web application. So it will have this login button that we'll click in a moment. And what happens under the covers is that user is being redirected to keylo because we'll be using the authorization code flow. User fills his credentials and our application gets the authorization code back. Then we need to uh fetch our client secret

and use both the authorization code and that client secret to obtain a set of tokens. So this is how the code looks like that we'll be using today. Uh let me walk you through it. First step is redirecting user to keyloak. As you can see we'll be using the uh endpoint. We need a client ID and a redirect URL to do it. Redirect URL is the landing

URL that Glo will browser to when he obtains authentication. Um and then we op uh in the next step we obtain the client secret and then we exchange the client secret to a token. As you can see we need the client ID, client secret and the code for it. And the last step is to do something with that token. We'll just display it on the page. So

here's the client secret. We now hit the login with keycloak button. I'm putting my credentials in. I'm getting back to the application. And that's the token our application obtained from keycloak. And there are a few things to uh to notice here. First have a look at the issuer. That's our keyloak instance. And that's actually realm called Kubernetes. And the other thing to notice is this is basically

my account. So a very wellestablished in the industry way of doing the user authentication. But now you can probably see that we have this client secret which needs to be confidential and we need to keep it confidential and that's a little bit problematic. So we can do a little bit better. So let's use the client assertions to do it. And the the flow is very very similar.

The application redirects user to keycloak. We obtain authentication. Now when we exchange code to a token, we don't need that client secret. We just send a token mounted to our pod by cube which is bound into our service account. So the code looks very very similar and the most significant difference is here which is the client assertion. We are basically telling keylog that we'll be sending a

service account token and we include the token mounted into our pod by cube. So let's have a look at it. This is the uh the token mounted into our pod into the application that you see. And first it's created for our kiklo instance as you can see by the audience field. Then we also have the subject claim which is basically our service account. That's my application running

in my nameace. So again let's login into keycloak. I already logged in so single sign on probably will work. and my application obtained a token from keycloak. So as you can see there's no secrets on in the be we just exchange uh a token mounted into my application by cube for a token and the third case I wanted to show you is machine toachine authentication so my

web application authenticates to keycloak there's no user in this picture so that's client credentials and in this case I'm using again the token mounted into my application and I'm exchanging this for a token from hecloak. No secrets needed whatsoever. The code is very very small. It fits you know in a couple of lines and it's very similar to the previous one but now we are using the

grant type client Um again similar case I have a token mounted by cube into my pod and I can get a token uh from keycloak and now what's important in this case I'm using the uh client um client service account instead of user service instead of user account. So now let's have a look at uh keycloak admin console how to configure all those things. First let's have

a look at the client secret um at client secret client um which is basically a confidential client um it has the client authentication turned on and if you navigate into credentials tab it uses the client client ID and secret and if you look at the client secret it's it's basically client secret now these two the one that my application uses is and the one configured in keylog

they of course need to match otherwise I I wouldn't be able to obtain now in case of signed JWTs first I need to establish a trust relationship between keycloak and my cube cluster and I do it via identity providers that's a notion of establishing a trust I can add a new cube identity provider I have already one configured for me and there are two things to uh

to remember here. First, I'm using alias. I need to remember it. I'll use it in a second. And I'm using the issuer URL which is pointing to my local cube cluster. Then I need to go to clients and I use the federated JWT client. Again, if I scroll down, that's the confidential client. It has the uh I need to fill the credentials tab and here I'm using

the same assigned JWT federated. I'm using the same alias I mentioned you know a second ago in the identity providers section and I'm binding everything into the service account of my application. So now this client configured in keylog trusts not only my cube cluster but it knows this will be my application trying to obtain authentication and this service account needs to match the one that I obtained

from my token to my mounted into my application. So those two things need to match. So getting back uh you can have a look at this demo in my GitHub if you would like to play with it. It should work fine on Mac. It should work fine on Linux. Um I tested it on Mac. Um so when to use this? It's a great way of uh doing

client authentication if your application is in the same cluster as your keycloak because everything works out of the box. If you're doing crosscluster authentication, you need to establish uh trusted CAS. If you're doing self-signed certificates, that needs additional setup steps. You need to add these CAS to kicklo and you need to have distinct issuer URLs for these clusters. >> I'm sorry, >> some of the course adjustments

or it's not required >> course adjustments. Yeah, like for the like if you're using a different >> on the application layer. Uh I don't know from top of my head. >> So you had some earlier on as well. >> Could be. Could be. Um and there's one limitation to have in mind. Cube uh will rotate your tokens every 10 minutes. You cannot set anything less than that.

So that's one limitation to have in mind. That being said, let me hand over to Alex. >> Yeah, thanks for that. uh demo. Um I think we skipped some of the other authentication mechanisms of clients. So there's some you can actually use uh key pairs to authenticate clients. That's also possible. >> True. >> But hey, if you can use that, why would you use anything else? >>

Yeah. >> Um then jumping then ahead. Well, we also promised to do an update on what's upcoming um in in Keith uh in the next releases. So what we saw here this JWCT au authorization grant which is preview 26.5 it's now going to be supported in 26.6. So this is the thing that allows you to um have users authenticate in one identity provider and then use applications

in another federated client authentication. Basically that demo what you saw here is the preview feature in keeper 26.5 that we published in January. you download today, you can try it out and with the end of March release, it's going to be fully >> can you wiggle your microphone box because it's >> Oh, so my microphone is off. >> Uh, want to Well, I can't switch it on

and off camera. Maybe the battery got lost. >> But then it maybe I can Can you use >> Mine works? >> Your work. >> Sorry for this. >> You got it. >> Yeah. Okay. Now, now we have a working microphone again. So, as I said, the JWT is it still working? >> You keep this. >> Okay. And I think we have a bad battery in here. Is

there a battery here? No worries. Sure. I switch it maybe. >> Okay. One, two. >> There you are. >> One, two. >> Thank you very much. >> All right. That's what I was saying. I was talking about the key 26.6 release. JWT authorization grant is going to be fully supported. That that's when you use uh authenticated user in one space and then use it in another space

to access application. Federated client authentication going to be fully supported. That's the demo we saw today. Um workflows, the user life cycle management are going to be fully supported and it's also the great thing that you can extend it. So you can write your own actions. Um if you or a friend of yours or a colleague of yours can do some Java programming that's a prerequisite but

then you can write an extension on clut cloak to have your custom actions uh in workflows. Organization groups is there so anybody using organizations might be happy to see that. So you can have organizations well having specific groups uh rolling updates and graceful restarts. So we put a lot of work into that. Um so that you have a graceful shutdown of keycloak rolling updates for patch releases.

Um um yeah and also better integration with traffic and envoy when especially when you're using uh MTLS to authenticate uh users or clients that those is then really um passed through the right headers and whatever else you might need to have that all available in in key. Um the database setup is going to be a bit more opinionated and simplified. For example, how to specify TLS certificates

for database connections, how to set up timeouts. We got some user feedback that it was sometimes difficult to configure the right timeout for failover scenarios um that it took longer than expected. So when you now have uh with the latest release you will have some preconfigured timeout that that should be a lot smoother when you do failover between database nodes. Um there's also a new keylo test

framework that will help you when you write your own extensions uh to test those. Um yeah that was a long journey but finally it's there. It's really working well. It's also helping us to speed up our internal development of kiklook. Kikl 26.6 6 will be out end of March. But then what happens after that in 26.7 and onwards uh we're working on skim support. So people who

want to do this um LDub over HTTP um they can do that and syn eventually synchronized users across uh instances of IDPS. Um organization roles is also in the works. Um we continue the work around MCP because well um we might eventually have more non-human users than users human users. Um so that all this integrates very very nicely. Um and what we once we then have databases

set up in a more opinionated and good way. We will also plan to do then have better documentation around proxy configurations and some blueprints around that as well. And if you have some ideas that we should put on our road map, please come by our stand at 2:00 uh from 2:00 and and let us know what's happening there. All right. And with that, we're at the Q&A.

Um this is also the link to the slides. The slides are also available on sket if you want to download them. And yeah, we have do we have five minutes for questions? Yeah. >> Like this. >> Um do you have anything because I would love to see something like um spire in in key. Is there anything like that in the word works or are you thinking about

something like that like the actual issuance of um spits directly in key? >> So the question was uh are we planning to integrate like issuing of spiffy spire things out of kelo? Um no we're just consuming it at the moment and that's no there are no plans to add anything more than consuming >> and you use the fine grain permissions to allow I would say some organization

style admin to manage all the users from one organization. >> So the question was about organizations um if we can have fine grain admin u fine grain permissions also to restrict access to a single organization. No not yet um it's on the road map but yeah you're not the only one waiting for that one. >> Uh do you support running That's good. >> So the question was,

can you run uh key clock outside of Kubernetes? Yes, you can. Um it's uh and it's also well supported. We just had a user survey and I'd say probably 50% maybe even two3 running it outside of Kubernetes and then use it also to well you can use it to connect to Kubernetes as well. People are doing that. I mean I mean using the service account login. >>

Um yes you can use yeah well the question was can I use can I have multiple key kubernetes clusters with the applications in there and then they connect to one single instance of yes this is possible uh but then your different keycloak sorry kubernetus clusters needs to have a unique issuer. So that's otherwise we can't really distinguish the tokens between them and keycloak must be able to

fetch the keys from that issuer URL. So and in some Kubernetes cluster that's a bit difficult that you need to have like a token to actually fetch those which is I think surprising >> if you look at WS then you can see how it does the token review IP. >> Uh okay well maybe we have a chat afterwards. Good. All right. Is it possible to manually upload

the JSON web keys for the issuer instead of adding the URL? >> Yeah, I I can probably take this one. So the cube identity provider that you saw I that I used during the demo is basically an extension of the OIDC identity provider. So you can also use an OIDC identity provider. You can put all the keys there if you want. You can even copy paste them.

So you can just take the JWKS URL content. you can copy it into the OIDC identity provider and use that instead like it's al it's all >> So it in the end the fun the foundation of that is as generic that you can use more or less any JWT well almost as usual. Last question maybe. Yeah. Does the organization grant um work with the token exchange flow?

So if I'm given an access token, I want to exchange that for another access token to go and use on service. Can I use the injected service account? >> Can I use uh it with token exchange? Probably yes. >> Yeah. Yes. Yes. It was the answer in in front. Yeah. Yeah. Okay. >> All right. I think we're on time. I think we had an half an hour

in total. >> So, thank you very much and at 2 o'clock, see you there.