Modern identity and access management: Configuration as code for Keycloak with Terraform @TNG

Consider a company that grows steadily in employee numbers and the amount of web services it uses. Additionally, consider the time spent (wasted) logging in to many of those web services separately each and every day – for each employee. The advantages of a company-wide identity and access management (IAM) including a single sign-on solution (SSO) become quite apparent. Keycloak uses open standards to authenticate users of a company's internal applications, and also supports external services, such as Slack or Zoom. Unfortunately, it lags behind on what has become the standard for maintaining IT systems: Configuration as Code (CaC). That's where the Terraform Keycloak Provider comes into play. Here at TNG, we have adopted and contributed to this quite mature open source project.

tl;dr: We contribute to and use a Keycloak provider for Terraform to manage our authentication server. Quick and reliable iterations on this very critical infrastructure component are now possible using our usual software development methods and high standards.

We compared several candidates with respect to the required additional development effort and our stability goals. The Kubernetes Keycloak Operator is a relatively young project and thus not battle-proven enough for our purposes. Another way to abstract the Keycloak API is the Keycloak Ansible provider. However, here we had non-optimal experiences from previous projects, including a challenging state of the tool's documentation. The third candidate we looked at and finally chose to use, was the Terraform Keycloak Provider. Importantly, it supports LDAP user federations as well as an adequate number of Keycloak's role mappers and it enables automated provisioning alongside manual configuration.

At some stages we had to patch the provider. The maintainer, Michael Parker, reacted quickly and we collaborated on our pull requests. By now we gathered quite some experience extending and maintaining Keycloak via Terraform. To us, it seems as straightforward as manual configuration in the UI. Terraform modules hold our client configuration and allow us to tune and test different parameters quickly. Any misconfiguration can be quickly fixed by rolling forward or rolling back to a working version. Furthermore, we mitigate missing features in the provider by completing the configuration manually. This hybrid approach also allows lightweight experiments by falling back to the UI. 

After transforming our Keycloak configuration into code, the migration of our Keycloak instances to Kubernetes was a non-event. As it should be.

What do think? Feel free to reach out in case you have questions or need some support!