Ep. #108, Securing Environment Variables with Dante Lex of Onboardbase

Brian Douglas: Welcome to another installment of JAMstack Radio.

I'm B Dougie and on the line I got Dante from Onboardbase. Dante, how you doing?

Dante Lex: I'm doing great, thank you very much.

Brian: Excellent. Well, you're calling in from Lagos, Nigeria. It's been a while since I had a community member in the JAMstack from Lagos, so how are things out there in Nigeria going for you?

Dante: Lagos is pretty good. Nigeria is awesome, just the weather here has been quite rainy and, yeah, really hard to step out of the house.

Brian: Well, hopefully your summer gets better and the dry season's coming soon. But I didn't bring you on to talk about the weather, really. I brought you on to talk about Onboardbase, but before we jump into that I just want to get an understanding of your background. So who is Dante and why are you here?

Dante: I'm a software engineer and a product designer and I'm building Onboardbase. In the last 10 plus years I have joined and led teams both on the design front and the engineering front, which is where I began to solve the problem that is Onboardbase.

That's where the problem initially came from and why I got so interested in it, because as I've worked in a couple of places as a contractor sometimes it's a problem I've tried to solve in different ways but never really got the nail on it. So that is why we started building Onboardbase.

Brian: Yeah, and can you go into what Onboardbase is? Looks like it does quite a few different things so I'd be curious as to how would you describe it?

Dante: Onboardbase syncs up to infrastructure for dev teams to securely share and work with environment configs across every stage of development, without compromising on security. In your team, especially in growing teams, you tend to hire junior devs and contractors, and you build a collaborative space for them to work securely, right?

A whole lot of tools these days don't handle this properly and teams have tried to solve this problem in several ways that are not ideal, so that is how I would describe Onboardbase.

Brian: Okay, excellent. I have a mental model of what it does and the problem that it solves, and I currently am working on a product that we do have contractors who I'm working alongside with and things like my Netlify login. They're not part of the Netlify team at the moment because at that point, adding one more team member for whatever, $20 per month at this point, not as ideal for me.

Especially if they're going to be a short run person that's going to help contribute, I also have open source contributors as well that aren't part of the team as well, so I'm enticed to understand how do I secretly pass around environment variables and tokens? And how are you doing this securely?

Dante: Okay. So firstly you described a scenario that is very prominent in a lot of teams. What most teams normally do is probably copy and paste over a communication channel like Slack or email, right? So then the engineers now copy and paste it into their codebase. What we at Onboardbase do is we take those secrets, we store it in a vault for you and then you can easily add your teams, and this syncs directly into their codebase itself through their terminal.

So one, they don't get to see it, two, you the admin have absolute control meaning that you can give them both specific environment assets, meaning they don't need to have access to production environment configurations. So probably only maybe development or staging, right? We don't change anything within your workflow, we just make it in realtime sync and completely secure.

Those secrets are encrypted and decrypted directly in your system, so we don't even have access to it, and we try as much as possible to take the liability away whereby we remove any password use case. We don't support password at all.

Brian: Okay, that's intriguing too as well. So by storing these environment variables, am I interacting with the Onboardbase dashboard and I point all my contributors, team members to the Onboardbase dashboard instead of going onto individual developer tools?

Dante: Yeah, so what you normally do is go to Onboardbase dashboard, create your environment variables with specific environments and then sync them to whatever cloud developments system that you currently use. No matter the cloud development system, we sync to every cloud development system available right now.

We've built certain use cases for it. What you then do is install the CLI for your local dev team, and that CLI continuously pushes those secrets directly into their codebase. They don't get to see it, they just actively work with, meaning that when you change it in one place, it changes across your infrastructure and syncs directly into your team's development environment.

Brian: Excellent, yeah. I like this for the use case which I had mentioned earlier with OpenSauced. We do have some production level stuff that's supporting our Hot.OpenSauced.Pizza product which is essentially product hunt for open source. I take contribution pretty regularly and a lot of times there might be contribution that needs to touch the database or the API.

What I've done so far is two contributors now have access to Supabase as part of the Supabase team, and as they work on it, basically I... Currently Supabase doesn't charge per seat, which is why I do this, so they have access to each seat. But in the event that I take this product into something that needs to have a little more security and even some audit logs and everything like that, that's something that I know I can't just invite random open source contributors into the database.

Currently, the database doesn't have any sensitive information, so that's why it's also okay. But the new thing that we're working on actually will have a portion of sensitive information that needs to be encrypted. There's a lot of questions and concerns around how I'm going to be orchestrating it and setting this up, so while you were talking I actually signed up for Onboardbase and I actually am going to be looking forward to using this. What is this? Like the first five minutes of this podcast, you already had me sold. I already appreciate you coming onboard.

Dante: Awesome. Thank you.

Honestly, this is something that is very personal to me because I've experienced this in so many ways and I've tried to solve it in so many ways. I've tried to use Notion, I've tried to use an Excel sheet, I've tried to use separate Git repos to solve it, but none of them still were able to solve the, one, being collaborative, two, for it to sync across my infrastructure right.

So one way Onboardbase excels is the collaborative aspect of it, meaning that while your team mate is maybe working on specific things locally, they can make major requests for specific secrets that they need. Meaning that, when they make those major requests, you the admin, will go to your dashboard and either accept or reject it based on certain reasons.

This then syncs in to every stage of development I currently have. With Onboardbase you can also see where your secrets are and when they are being used, meaning that you can literally stop those servers from running or restart them if you need to. So this gives you real time observability of your secrets as well.

As much as possible we've tried to build real live use cases into Onboardbase to make it collaborative, secure and ease of use. We are saying, "You know what? You don't need a security engineer to set this up. You the project admin, you the developer, can easily get this security up and running in almost no time.

Brian: Excellent. Yeah, I love this. In the notes actually my mental bottle actually goes to Vault, Vault being a tool from HashiCorp being able to manage secrets. From my understanding, Vault, I don't know if it actually has a GUI at all, but I know Vault is pretty useful for backend engineers because you're already SHHing and leveraging Docker images and stuff like that, it's one more CLI to manage.

So how does this compare to Vault? Maybe my assumption is that maybe this is going to be a little more advantageous to folks who are on the frontend, but let me know if I'm out of bounds on that.

Dante: Well, Vault is a great tool but if you've used Vault before you know it's not easy to use. You probably need a more security engineering based person to set it up, which is one of the cases where we are saying Onboardbase is easy to use, anyone can literally set it up for your team. You don't need a security engineer to do that. Also, Vault is not good to account for collaboration, meaning that if I'm working on something separately, there's almost no way for me to actually make an MR or make a request for this to be added.

I have to contact my engineering manager, "Hey, we need this," explain why I need it before it can even get merged. No, you can do everything directly from Onboardbase.

So you add the secrets that you need to use or based on the environment that they need to be added and you put a comment to it as well, why it needs to be there. The engineering manager sees everything on another view and they really just add it for them.

You, the engineering manager, can also add notes specific to each secret so that an engineer can easily go and have an overview of what the secret is for, knowing it needs to do, what amount, explain anything. Everything is handled by Onboardbase, and there's a collaborative aspect as well, a real time aspect that Vault does not also account for.

I honestly used to love Vault because it brought this problem to the front and center, but it felt like they stopped innovating and it just became something that you would need to have a very secured engineering person to use. But that's not the way the world is, the world is changing, teams are going remote and hiring more across the globe. You need someone to easily set this up and begin using it. Basically, we're making security administering. Let me put it that way. So you just set it up, get started.

Brian: Yeah. I cringe, but also I do the same thing when you talk about passing around environment variables in Slack and Excel spreadsheets, et cetera, et cetera. Obviously it's hard to keep track of the security of your product when you're passing around Excel files or having shared Google Drives that have sensitive information. That's a nightmare waiting to happen.

But when you approach it in this way where now anybody could basically... I was able to login and setup a project, and now I'm at the point where I can just upload my M file. That's amazing and that's exactly what I need, because what I need to do is have a centralized location of where stuff needs to be updated and changed. But also I need to be able to, not let go, it sounds bad if I say let go of somebody, but remove access at the drop of the hat if I needed to.

So not that I have any security concerns, but people come and go and they move from project to project, so where I'm sitting at where I have a project that has very limited sensitive data but has multiple open source contributors across the globe that need to contribute to this thing. Now I don't have a blocker to get people access to things to help and work alongside me as I develop the product that I'm working on.

Dante: Yeah, and we tried to make it as contractor friendly as possible, meaning that you can easily switch between accounts as a contractor, so switch between organization also between product networks.

We tried to account for real life scenarios. I've seen some tools that try to account for the best case scenario, but the world is not usually the best case. It needs to account for mistakes, it needs to account for a couple of things that happen within development.

For example, we recently shipped something that scans your code locally and makes sure nothing like secrets are being committed. So we are not saying when you get into your Git repo, then you start it. No, we are saying, while you're still local you should scan this codebase. So in case an engineer makes a mistake, I can easily catch it at that point before those things make it even into the Git repository. We are being proactive to how you are developing as a team, rather than where you develop.

Brian: Excellent. Yeah, it sounds like you're in the right place at the right time. I don't think the world's getting less remote, I think the remote culture is going to be turned up to 11 even more so, and I also think that the access to engineers where they are at currently is also extremely valuable.

So folks, they want to hire in Nigeria, they want to hire in Brazil, they want to hire in Singapore to be able to make sure folks can onboard without a lot of friction. It seems like this is one step in that puzzle as well. My question to you, I see the integrations and the setup, it seems to be pretty straightforward, what's next for Onboardbase?

Dante: We see Onboardbase as where product development starts and continues, while improving work experience through secured and centralized environments. So while we've been able to secrete environment variables as a service, we want to begin to create environment as a service. We want to build out a remote development infrastructure next after our secret infrastructure. So while we are in parallel development, we also want to help people control those development environments that they currently work with.

While I've been plagued over the years about managing environment variables, I've also been plagued about, "it works on my local machine but it doesn't work on development." It's something I actively still experience, so we are beginning to build up more development infrastructure for that. All these things tie directly into Onboardbase.

Brian: Okay, excellent. Yeah, you just got a new user while we were just chatting. I'm actually very intrigued by what comes out of this product next, because I think this is extremely useful. Just yesterday we setup a new API, so the API service that we're leveraging is going to be consumed in multiple products, open source products that we're building for OpenSauced in particular. In order to set this up I actually tested a couple different deployment platforms, to be quite honest.

I deployed it at Digital Ocean, deployed at Render.com and then Railway was the other one I deployed it to. Oh, and Flight Control, I deployed it to Flight control. I was just trying to figure out, it's a new service, I've got some new problems and a new model that I need to... Not a server, but I needed some extra... it has a database attached and everything like that, so needed to try some new services out.

But in order to try those services out I had to copy and paste the environment variables to each service and I think there was about 12 environment variables because we have a Docker image that runs in this, a bunch of other stuff that happens.

It's pretty nifty stuff, but I guess what I'm getting at is, it would've been really nice to connect Onboardbase to whatever provider deployment platform that I was going to deploy to, click that sync button and then deploy, and that way technically we could test out multiple deployment platforms without needing to copy and paste the entire environment variables.

Because most platforms, it's one variable per line, which I guess in most cases that works. But if I want to sync that across from Digital Ocean to Netlify to somewhere else, yeah, it'd be nice to have just one source of truth.

Dante: Yeah. We actually use a whole lot of servers because we try to maintain a multi cloud infrastructure, so we almost never go down. This is actually a nebulous view that a whole lot of integrations and documentation for several different servers, and if you don't want to use our CLI, we also maintain three SDKs, JS, Ruby and Python so you can also use that if you need to.

If you want to also build your own SDK we provide a couple of API reference. We went ahead to help you write a proper documentation on how you can actually encrypt and decrypt secrets. I don't think anyone, any platform has actually done this, but we did this because we know when you're building your own SDKs you need to be able to decrypt and encrypt secrets.

Brian: Okay, excellent. Yeah, so I'll definitely be checking that out. I basically signed up as we were chatting, but do you want to explain how people can get started with Onboardbase?

Dante: Yeah, so once you get into Onboardbase you sign up, create an account, you upload your ENV and then connect it to any server you currently use. We also send you an email inviting you to the Onboardbase customer community whereby we assign you a specific and dedicated engineer to your account.

The reason being, that sometimes there are some use cases that we may not already have accounted for but we can easily put up a guide for it. So we'd discuss with the team on whatever their use cases are and help them easily get started or setup.

Brian: Okay, perfect. Well, yeah, I look forward to engaging with those folks. Like I said, I'm ready to use this thing. This thing is going to solve a problem, a pain point that we have currently, literally yesterday, so can't wait to leverage it for that problem. I'll be in touch if we have any questions and if there are any use cases that we come across.

Dante: Awesome. I'm sure you will get that email quite soon.

Brian: Excellent. So Dante, thank you so much for coming on and talking about Onboardbase. I do encourage everyone who's listening, go to Onboardbase.com. Yeah, definitely check it out, signup and test it in at least one environment, one project and invite some team members on there. Yeah, with that said I want to transition us to picks, these are Jam picks, things that we're jamming on. Could be music, technology related, all of the above, and if you don't mind, I'll go first?

Dante: Sure.

Brian: I actually just recently came across a tool because I'm using Supabase for my database needs and actually authentication needs as well. There's a tool called Dashi Base, it's extremely new, they're still just getting started, and what it does is it provides a dashboard on top of your Supabase tables and your... basically all your Supabase Auth and everything. It's pretty clever, and for folks like myself who I do have folks who integrate with the open source project that need access to like an admin dashboard.

We actually originally started building an admin dashboard for my project and it was really because we're trying to find out top open source repos. It's Hot.OpenSauced.pizza. Top open source repos and we just want to be able to feature one repo, so to do that we have to go into the Supabase table and then mark it.

So instead it would be great if anybody, community member, can feature an open source repo just by flipping a flag true or false, or going into an admin dashboard and flipping a true/false. So with Dashi Base it gives you a GUI interface on top of that table so now anybody on the team can interface with it. That's my first pick. My second pick is this book called Sprint.

Sprint is a book that I recently picked up as I was planning on trying to ship product quicker. It's a book, actually the guy I'm working as a designer with, he had recommended us leveraging it. It's actually been super helpful because I've always worked in sprints, I've Agile methodology. But I've never really sat and thought about that, I've always been dictated as an engineer, "This is our spread, this is how it works."

But never I took a step back to understand why and how to get feedback. So I highly recommend it if anybody is working on an Agile team or if you're working on a product, even a solo product. I recommend setting up a Sprint so that way you can see what you can get done in a structured amount of time. So definitely check it out. Dante, do you have a pick for us?

Dante: Yeah. It's something that I've been researching a lot, self hosting as a service. It's something that constantly comes up for us, teams requesting for, "Hey, do you have on prem and the rest?" I've been looking into this space and trying to figure out why currently there is no solution for it, and I can tell you it's for very good reasons.

But I still feel that there are a couple of things around self hosting that cannot be automated, and I look forward to when we get to a stage whereby we can have a solution like this. Something I always like to tell people is the process to actually making something simple is often complicated, so don't be deterred or discouraged whereby you're trying to build something or you're trying to learn something and it's quite complicated as well.

Don't worry about it, you are getting there. The more complicated it is at the beginning, the simpler it will be at the end, so that's my advice for people. In terms of book, I've been reading this book by Andrew Gazdecki, How To Get Acquired. He's the CEO of MicroAcquire, so I've kind of been reading up on it, and pretty good insights honestly. I'd say anybody should go grab the book and get reading it, you can't believe how much gold is in it.

Brian: Yeah, it's funny. I follow that guy on Twitter. I don't know how I stumbled across him. I did see that you were part of OnDeck, maybe he was part of OnDeck as well. But yeah, he has a lot of insights, he's worth following on Twitter. I did pick up the book, I haven't read it, but I look forward to thumbing through that. But if you're recommending it, I'll definitely try to get to that in the next couple weeks.

Dante: Yeah, you definitely should because it's a great book.

Brian: Perfect. Well, thanks so much. Awesome conversation. I will be in touch definitely about this product, as well as listeners, try Onboardbase, do not store your secrets inside of a Google Drive or an Excel spreadsheet, or similar or Slack. There's a solution for you, it's called Onboardbase. Don't forget to keep spreading the jam.