 Hi, I'm Cameron Cedar, and in this session, we are going to talk about selecting the right identity provider for Kubernetes, a comparative survey. Now, I work for SUSE as a technology strategist, and I work on many of their premium customers' accounts and strategic opportunities. I've worked in this industry for many, many years and have lots of experience in many different areas. And hopefully today, you can get some good information from some of the experiences that I've had working with Kubernetes and identity providers. So, who do you trust in this ever-evolving web of identities? I hope to be able to talk about identities, the where, why, how, and things, and identity providers for Kubernetes specifically. What identity providers are available and what are the common markers of interest. And also what common marker comparison is available today, and how we can conclude on the right identity provider for me. So, let's talk about identities. Now, identities have gone through lots of evolution over the past few decades. But if you think back from the invention of the transistor to having billions of those transistors in the palm of your hand today, think about what it took as a community to come together to create such invention. And we're mostly, throughout time, we've been creating kind of our own problems and unique solutions. And it's all through community. Through time, transistors have really changed the world. And if you think about identities in the way that we've evolved to having applications running on top of our cell phone, our identity authentication has changed in ways that we never even thought possible. So being able to overcome challenges such as providing authentication for different types of applications that are running on our phone and maybe having that application touch, you know, different identities or even gather information from our identity that might be common information that could be used between other applications. So it's kind of interesting how we've kind of helped perfect that. So by way of communities and technology, we're kind of becoming more perfectionist in this way. And there's two things now that really kind of stand out and really have evolved and that's authentication and authorization. So in terms of auth n, which is authentication, and then auth z, which is authorization, there's a few different strategies here. So with auth n, you typically have client certificates or SSL or some type of token, whether it be a static token, an open ID connect token, web hook tokens, bootstrap tokens, service account tokens. And these are very common amongst Kubernetes itself. You could also have a static password or some type of anonymous request if it's temporary. In auth z terms, there are a few different strategies. We've gone back and forth between RBAC, which is role-based access control, or ABAC or authorization control web hooks and also node authorization. We also need to compare things like different protocols. So we have things like SAML versus OAuth and OIDC, which is open ID connect. And what's interesting over time, SAML has been very popular amongst identity providers in the past, where you just look up an identity and see if that user is able to authenticate based on a password or token of sorts. But now we've kind of moved into this world of using OAuth and open ID or open identity connect. And this methodology combining those two together gives you the best of both worlds, gives you the ability to both authenticate and do some authorization. So very early on, a lot of these use cases just really used SAML authentication, because that's really what was all that was required. OAuth 2 plus open ID connect gives us even more powerful capabilities to be able to do them several ways, plus some single sign-on capabilities, and also be able to use those in the mobile environment and also providing access to various types of resources. If you think around the time when authentication really started to pop up in mobile phones, there became the idea of, well, I need my identity plus I need to be able to capture contacts maybe from Google. And so I need to be able to connect that to maybe an application like Yelp. And so having open ID connect and OAuth working together gave us that capability. If you see the little picture on the right, that's kind of the common connection that we were able to connect our applications to these various applications and provide some authorized information to that application. And that still goes on today and many applications use that capability, which makes it a lot more powerful. And we're going to see more of that, of course. So OIDC and OAuth 2 Infinity and beyond maybe. So we have OAuth N, we've got OAuth Z, we've got that seemingly a little bit figured out, but it is complex. It's not something that you just go and start using. You have to learn how it works. You've got to learn how to program for OAuth and OIDC. So for developers, it can be very complex. They don't really want or care for managing tokens or cryptography, but they want to be able to authenticate users and check their access. And so they need some sort of client library in order to make that possible. Make it really easy. It's important to bundle in some type of client library for developers so that they can do this really simply and easily. Now you have the Kubernetes way of authenticating, which is fairly straightforward. You have authentication, you've got authorization, and then you have the admission control that all takes place within the Kubernetes cluster. Now Kubernetes provides several different plugins and there's also the basic authentication as well, which is all base 64 encoded. And then there's also OpenID Connect, and it also has the ability to connect up to LDAP and several types of token authentication. And you can go on and on, counting the different ways. So there's lots of possibilities there. But if you want to scale that, of course you need an identity provider or some other methodology to plug into that. And that's why we have the different plugins. So identity providers for Kubernetes. This is kind of a typical identity provider architecture when it comes to Kubernetes. This is what I see a lot of people doing. And you'll see this very commonly for out-of-the-box solutions for Kubernetes distributions where you have an LDAP store that has your credentials. You have various users and passwords, etc. And you'll typically use DEX. Another one might be UAA, but DEX will provide the ability for you to plug in with OIDC or use some type of other authenticator such as Gangway in order to provide login credentials and the authentication and authorization tokens. And to do it in an easy fashion and to really provide it in a way that can make things easier and a little more extensible. So do we really still need LDAP in 2020? Well, that's a really good question. And it really might depend on your use case. It's been proven. LDAP has been around for a long time in the enterprise. It's easy to do migrations from other identity providers into LDAP. It's used as a base for a lot of unified single sign-on solutions. And you may already have it somewhere in your enterprise. And it's deployable on Kubernetes. Now, the negative side to that is the declarative side of it is not always sufficient. And it's stateful. So you really better make a backup or you might have some type of a way to synchronize it which may not always be possible, which also doesn't scale very well also. In an LDAP sense, a scale-out methodology is just not there if you want to do thousands of logins per second. That's really hard to scale with LDAP. And it's not typically usable as is. And so you have to do a lot of modifications and you have to set up your configuration file for SSL and various other things. And you don't get any two-factor authentication. And so you might want to use something like a NoSQL database like Couchbase, for example, that help provide an LDAP interface but yet is able to scale out both in a cloud-native perspective or on-premise. Now, portals to the rescue. Portals to another identity provider. If you are using DEX or UAA, you can use these other OIDC clients. There's the Gangway, which I just showed in the architecture example. Or you have the DEX Kubernetes Op-indicator, which is also available. And there's lots and lots of others. I believe when you Google search it, you'll see at least two dozen different types of OIDC clients that you could possibly plug in with DEX or UAA as a use with Kubernetes. But these don't always scale. They're not always capable of providing thousands of connections a second. So if you want something that is used both for your Kubernetes administration and for your applications that are running on Kubernetes, then this is probably not the solution for you. Then there's the Outstanding in the Crowd. And these are the ones that actually have some real open-source street cred. And we have Glue, which their goal is to be among the first vendors to support all of the new essential features of OAuth. And they've done a really impressive job with that. And then there's Key Cloak, which is also open-source. It's driven more so by Red Hat Community. It's open-source identity and access management for modern applications and services. And we have Open Unison, which is combining the common identity management functions needed by most applications including single sign-on, user provisioning, federation, web services. And Open Unison can run on any J2EE containers such as Tomcat or JBoss. And then we have Open IAM, which started in 2008 with this mission of making the business of managing identities effortless using innovative approach. So they all really have similar goals, but their technology differs slightly in implementation. So let's take a look at some of that a little bit. Some of the common markers of interest that I want to pay attention to are Identity Federation, Open Source, because if you remember when I talked about earlier, going back to the transistors and how those came about and how we now have billions of transistors in the palm of our hand, it's always been about community to bring that about. So when you take a look at Open Source, Open Source makes a big difference in the way that we implement and provide this software. If you look at the way that OAuth has formed to be able to tackle these solutions from applications on our phone, it was a community of users that came together to create OAuth and find solutions to these problems. We'll also look at protocol support for Authent and AuthZ, different types of second factor authentication, ways of doing user management. Do we have automated client registration? Do we have different types of back end support so that we can do scale out and support up to thousands of users per second? What types of languages are we writing this application in? And let's look at the healthy markers of a developer community. And do we make it easy and deployable on top of Kubernetes? So what's best for me? Let's go ahead and compare these. If we look at these markers that we talked about from a key cloak perspective, yes. Identity Federation is comparable across the board. Every single one of these solutions does provide identity federation. Now, what's really not common amongst them is whether or not that identity federation is provided as an enterprise edition version and you have to pay extra or it just comes completely free. In this case of glue, you'll notice that a lot of the features, in fact, everything that you see is what you get. It's 100% open source. Everything that is provided in the open source version is also in the enterprise version. In the enterprise version, you're just paying for support. And if you need help in setting it up or it's your insurance, you can call glue, get great support. They'll help you out with anything in regards to the software and getting it set up and getting a solution put together. That's what they provide. They are 100% an open source solution. When you take a look at key cloak or open unison or open IAM, all of these have some differentiators when it comes to an enterprise version of the product because they will offer certain extensions to it that provide extra functionality that you don't get in the open source version. You'll see some differences there as far as you'll see in some of the documentation. This enterprise version will support these extra protocols. If you look at the protocol support, they're pretty common across the board. You'll notice that glue does provide some extra stuff there. It's got some integrations with OPA, open policy agent, UMA and CAS, which key cloak does have some of that too, but some of that stuff does have a cost to it on the enterprise version. So you have to pick and choose which you like better. You like the pure open source version or do you like to have something that's a multi-source type vendor. There's the second factor out on occasion. If you compare all of these, they all have similar functionality there. From the TOTP or the OTP to the FIDO2 where you're supporting extra devices that you might like to use with the U2F functionality, and some of them only provide that functionality as an enterprise addition. For user management, they're all pretty common and some of those interfaces are better than others. So if you take a look at key cloak, really like their interface. It's really user friendly and what's really nice is it comes with the CLI. The CLI is super nice for administrators if you come from the command line world, whereas the others don't really provide that. Glue provides a really nice interface as well as open unison. Their interfaces are all very, very similar. They're very nice and easy to work with, very user friendly. As far as user management goes for having user management, being able to manage it themselves, going in and changing passwords and things of that nature, they all have the similar types of interfaces, very user friendly. Automated client registration, all built in with every one of those solutions. Again, their web interface, their interfaces in order to accomplish that are all very capable and very user friendly, very easy to use. As far as back-end support goes, most every one of them will support your active directories, back-end LDAP type back-ends, anything available there. If it's e-directory, it's all going to work there. There's others possible and some of these like key cloak will have some others possible. They also say you can support some type of databases as well, but your mileage may vary as far as whether that's easy to integrate or it's easy to follow through some documentation. Glue makes it super easy. It's all integrated with their deployment tools. You can deploy either with an LDAP service or you can deploy with couch base. It will go through some level of gateway synchronization if you want to connect it to Active Directory or other services. Open Unison has some similar things as well where it can do that with MongoDB, but I've noticed that as far as easily deploying, I would really give hands down to Glue as far as easy deploying because that's built into all their Helm charts and it just makes it super easy. Open IAM takes a lot more configuration and notice key cloak takes a little bit of extra configuration on that side of the house too. Across the board, they're all mostly delivered in a Java development framework and some are mostly supported on top of things like Jboss or some type of middleware. That might not be true amongst all of them. Open Unison certainly is not, Open IAM certainly not, but some level of J2EE so you might require some type of Tomcat in order to execute it. If it's deployed through the Helm charts, then that's typically going to be taken care of for you. Developer communities and all these are pretty well active. Open IAM, I can't really find a lot of information on their community development where that's really located. It seems like some of it was in GitHub and maybe it had moved somewhere else, but it's difficult to find, especially information on their roadmap. Glue is pretty active. You'll see issues and things and activity going on on a daily basis. They have a current roadmap available, Open Unison the same way, pretty active. I didn't find any active roadmap available there, but I'm sure that they have stuff available if you ask them. Key Cloak, pretty active community, no real active roadmap that I could see from the community, but they're a pretty active community from a daily basis with issues. They're resolving from a weekly basis, so their community seems pretty active there. As far as the architecture goes, the architecture differs on all four of them really. You're going to see a mix of client libraries that are provided and some client libraries mixed with some open source client libraries. You'll find a very open source library that Glue is providing, but it's a glue centric library. They provide this extra client library that you can program to to make things really easy from a developer's perspective. Open Unison and Glue also have support for many different languages. Key Cloak has some extra support for languages as well. Open IAM, I'm not quite sure about, but they do provide some client libraries that are common with some common APIs. Then of course, making this available for all Kubernetes, making it easy to deploy, making Helm charts available. I think Glue, as far as providing all that, but also making it super easy to configure and set up for many different scenarios, Glue has that down pretty well. If you want the easy road, they do pretty well there. If you want something that's certified, I found this to be quite interesting. An OpenID certification goes. You can go out to OpenID and check out the certified OpenID provider servers and services. Whereas Glue has the Glue Server 4.x certified there. Key Cloak is certified, although I was noticing it was a little bit older version, so they're not quite up to date there. There's also the certified financial grade API. The Glue Server 4.2 is completely certified. That's the newest version. There's also the certified financial grade API for the client initiated back channel authentication profile, which again is another certification for a Glue Server 4.2. I'm not seeing any other of these IDPs, these identity providers that actually have any commitment or any involvement in the OpenID certifications that are except Glue. I think they're making it a big point to make sure that each one of theirs is completely certified. Although others have made attempts and there are others out there, they've just been small attempts and they're typically older versions. But I can just use DEX or UAA. Yeah, you could. But I'm going to tell you, it's just really for those solutions where you might be more localized solutions, not a lot of users, might be for just administration of your Kubernetes cluster. It's definitely not going to be for your use case when it involves your applications and you want to build an authentication mechanism for your application stack that you have running there on Kubernetes. You really will want something that's more of an identity provider that you can utilize and scale out, give a nice scale out architecture for thousands of users a second, depending on your requirements there. But then there's UAA. UAA is also possible. You have some similar capabilities there with DEX, but you're still going to require a client application. And there's no certifications with either of these when it comes to the OpenID certifications. In conclusion, I really like to go with the outstanding crowd and it's really because of the certifications. It's really because the community involvement, the activity in the community that's going on. One that really stands out to me is GLU because they've really gone the extra mile to get certified. They've gone the extra mile to make everything 100% open source and upstream. They're focused on their community. They're focused on making sure it's open source. They're focused on the open standards, making sure it's enterprise ready, making sure you're innovating, focusing on all these OAuth policies and standards, various administrator tools that are available, and also developer tools from developer perspective, making sure that you have client libraries available. Making sure that you're covering the whole protocol base that's out there because there's going to be some applications that you might just want to use SAML-Auth with and others you might want to use OIDC and OAuth. And it's coming and you might see it very soon, OAuth 3. I think they're working on it now. They're working on some different scopes. There are still problems, right? There's still the community coming together trying to fix solutions to fix problems and come up with solutions to those problems in the community today. And we're going to see more changing in that direction. But I can certainly see things continue to evolve around OIDC and OAuth as we move forward and just enhancing that, making those things better. Hopefully this was useful and I hopefully enjoyed some of the content. Certainly leave some feedback and I'd like to hear more. Reach out to me. I'm on Twitter. I'm on LinkedIn. And we'll talk to you soon. Thanks. Bye.