Red Hat’s Keycloak Identity Access Management Bids to Join CNCF

The open source Keycloak is an identity access management (IAM) project developed primarily by Red Hat that has achieved broad adoption, yet the project is still striving towards one goal, as it has been since the fall of 2018 — adoption by the Cloud Native Computing Foundation (CNCF).

In its first bid to join the CNCF, the project aimed its sights on potentially becoming an incubating-, rather than sandbox-, level project, but the bid did not meet the requirements. Now, the project has again applied for inclusion in the CNCF at the sandbox level and has been steadily laying out support from users such as Bosch, Cisco, Hitachi and more. When the project first began to coalesce, with its first stable release in 2014, it took aim at one primary issue — the difficulty for many developers to easily add security to their applications.

There was “just a general feeling that identity and access management was way too hard, way too expensive and really not developer-friendly. If you were building a cloud native application, to wire up the security bit to do complex things like single sign-on, it was actually pretty difficult. So, a couple of Red Hat developers got their heads together and basically dreamt up this project called Keycloak,” explained Rich Sharples, senior director of product management at Red Hat in an interview. “If you’re building out a modern application, building in things like social login and federated security, and integrating with backends like active directory or LDAP, is actually still pretty difficult. It’s the kind of thing you really need to get right.”

At its core, this is really the bread and butter of the Keycloak project — easily enabling security authentication into your application, wherever it runs, and providing features like single sign-on, user federation, identity brokering and social sign-on, and an administration console to configure everything. Keycloak operates in both traditional and containerized environments and abstracts away authentication in a way that works regardless of your application’s architecture or the infrastructure on which it runs. Rather than signing in or out with the application itself, users (or microservices) authenticate with Keycloak, which, according to the project website, means that “your applications don’t have to deal with login forms, authenticating users, and storing users.” While containerized applications can struggle with the task of handling state, Sharples notes that “that’s a problem for Keycloak to solve rather than your application. You don’t need to worry about states, we can take care of that.”

According to Sharples, the project has had running in a containerized environment as a focus since its early days, with Red Hat OpenShift as an obvious target.

There’s a set of use cases around cloud native development and microservices where what you’re actually securing are individual microservices and the interaction between microservices,” said Sharples. “Where some other solution is way too heavyweight, Keycloak has always been designed with the cloud in mind and with running OpenShift in mind. It fits in containers pretty readily and easily.”

This focus on cloud native development was one that Kubernetes creator and CNCF technical oversight committee (TOC) contributor Joe Beda took issue with during the project’s first attempt to join the CNCF. According to Beda, the project didn’t “feel as ‘cloud native’ as many of the other projects in the CNCF” as the installation instructions were “clearly tilted toward more traditional environments” and “tied to the set of Red Hat commercial offerings.” At the time, Red Hat senior manager Boleslaw Dawidowicz, who has been handling Keycloak’s CNCF application process, argued that this issue was more one of documentation than of reality, pointing to a Docker image with more than ten million pulls. Concerning governance and external contributors, Dawidowicz noted at the time that a majority of the code had not been contributed by Red Hat employees and that “Governance model changes and more non-Red Hat maintainers will follow although I hope that from looking at our community channels the path is visible and clear in this area.”

Recently, the project saw the release of Keycloak 10.0.1 following an announcement that it was focusing on building a “leaner, easier and more future-proof” version of itself called Keycloak.X. With this new, yet-to-arrive version of Keycloak, the project looks to make it easier to configure, scale, and extend, with the addition of support for zero-downtime upgrades and continuous delivery. Alongside a “new and improved storage layer,” Keycloak.X also looks to provide a “new distribution powered by Quarkus,” an open source Kubernetes-Native Java framework tailored for Java virtual machines that is also backed by Red Hat.

Although Keycloak.X was announced last fall, Sharples says that the pandemic has put a bit of a kink in the process, noting that “our focus is definitely different, where rushing products out to market is maybe not the highest priority right now — helping existing customers with the situation they’re dealing with is really what we’re focused on.”

As for the project’s bid to join the CNCF, the process is ongoing, with individual users and vendors offering supporting testaments. The recent bid was initiated at the end of March, and this time focuses on joining at the sandbox level, with Dawidowicz writing that “I believe it is a matured-enough project to match Incubation. Although from past experience would prefer to avoid this aspect derailing the discussion and create doubts on criteria to apply.”

The Cloud Native Computing Foundation and Red Hat are sponsors of The New Stack.