Community Developer Brings HashiCorp Terraform to Auth0

Infrastructure-as-code is a powerful tool to help alleviate the pain of maintaining cloud architecture. DevOps engineers simply have to code a configuration file, feed it into a solution like HashiCorp Terraform, and viola! Changes occur to the appropriate cloud resources. Auth0's Terraform integration came from our developer community, written by Alex Kalyvitis, a software engineer. We sat down with Alex to talk about his experience and what he learned from it.

What Developers and DevOps engineers will learn from this interview:

• Why infrastructure-as-code for authentication
• What it takes to create a successful open-source project

Shafiq: How did you first learn about Auth0?

Alex: Like every engineer, you have to deal with the 300-pound authentication gorilla at a certain point. It's not core to your business, but you must get it right or end up with an insecure app. The consensus in the developer world is to let people who it is their core business do that. In my previous experience at Yieldr, we started with basic authentication to ensure only certain people had access. However, we realized early on that we needed more, and it became clear that we had to implement best practices, such as OAuth2 and Open ID connect, and not try to invent our own.

Luckily, some of the best authentication resources come from Auth0. I learned quite a bit from Auth0's documentation and thought that maybe I should use it instead of building one. I gave Auth0 a try, and after exploring features such as social providers, I realized that it was a robust product. I've been happily using it since.

Shafiq: Why did you write the Auth0 Terraform Provider?

Alex: Creating the Terraform provider started from an internal organizational philosophy of having all of our cloud infrastructures checked in as code. Doing this gives you the ability to manage all the things that support your infrastructures, such as Amazon AWS, Cloudflare, New Relic, Pagerduty, or other infrastructure or service providers. You can treat it with the same level of scrutiny as your product code. So if I make a change to my infrastructure, it's not by signing into a console and toggling the switch off or on. It makes moves more deliberate and safe.

As an example, once one of our engineers, while developing a new feature, he had toggled a flag in our Auth0 tenant. This broke our login flow. But we didn't immediately make the connection and instead wasted our time looking for a bug in our codebase. It took us about a day to figure out what happened. So at that point, we said, "All right, this has to be managed with code." Unfortunately, there was no Terraform provider for Auth0 at the time. So we decided to build one. I started by looking through the client libraries offered by Auth0, and unfortunately, a Go SDK was not available, so I had to make one as well to support the provider. Fast forward a couple of years, people are using it to provide their authentication infrastructure, with lots of contributions from the community.

Shafiq: Did you encounter any challenges, and how did you manage them?

Alex: Challenges. Yeah, I mean, there's always a challenge with any project with significant size or complexity. Building the plan, I started by drawing a line in the sand, so to speak, with whatever is supported by Auth0 and whatever is publicly-documented by Auth0. I used Auth0's management documentation, the API documentation, and that was my golden standard. If it wasn't there, it wasn't in the provider. So that's where I based off a lot of the original work.

Later on, of course, people started using it for things that were not necessarily detailed in the API documentation. So with some reverse engineering and by checking out what changes occurred in the dashboard, we managed to add additional functionality. That was challenging in a sense, but it wasn't rocket science, slightly a bit of guesswork. We built an API that, you know, approximates how it should behave.

Also, time, time is critical. I had to balance how much time I could allocate for this project. I had a demanding schedule at work, as we were building a complex product. Therefore building and maintaining the project was done during weekends and afternoons. Balancing that with home-life was a bit of a challenge. I suspect that some users may get frustrated by that, but there's only so much a single person can do, and I've done the best that I could.

Shafiq: What was your reaction when demand increased for the provider?

Alex: I was thrilled and delighted to see people finding it useful. I had built something people cared about. It's cool. Even though it's not on the level of developing the next Kafka or precious open-source technology, it's building on the shoulders of that. It's super exciting to see people care about your work and finding it so useful that they want to contribute to it. And some people are passionate about it that they feel that it's even their own even though I haven't yet met them in-person.

Shafiq: What did you learn from the experience?

Alex: You always have to be a good host to everybody. It can be easy to get frustrated by a comment or a request that might seem irrational or too far-reaching. But it's important to be level-headed and treat everybody with respect and point them in the right direction. If I think they're wrong, I try to be helpful because, in the end, what you do people see, and they act in kind. So, if you want people to act respectfully, then you'll have to be respectful and earn respect for yourself. And I see that quality in a lot of people, especially around isolated incidents. So, yeah, be a role model in the community that you want to support.

Shafiq: Why did you decide to make it open-source and not keep it proprietary?

Alex: Well, for starters, it's not something core to our business, as we're focused on building our product. Open-source is a great way to give back to a community as well as enlist the community to contribute. These are two sides of the same coin. So, on the one hand, you put a lot of effort and give something out for free, but you get more eyes and more scrutiny. This is a good thing, especially when you're dealing with something as sensitive as infrastructure. Crowdsourcing via open-source helps to surface issues we would not have foreseen or would not have the time to deal with.

Shafiq: What would you say to somebody who is considering writing open-source code?

Alex: Do it. Absolutely do it! The process will teach you a bunch of stuff because people, often smarter than you, may find what you do use and be inclined to share their knowledge with you. So in a way, this is a way to learn. For us, engineers, open-source is hugely valuable as we get to read and understand the world's best codebases written by some of the most brilliant people. That's a huge learning opportunity. I don't know why a developer would do something close-sourced unless it's critical to their business. Unless it's a core piece of software that is intellectual property and you wouldn't want your competitors to see, I don't know why not do open-source.

A special thank you to Alex for allowing us to interview him and for the incredible work he's done with Auth0's Terraform Provider. We highly value and appreciate the contribution our developer community continues to make and for the partnership cultivated over the years.