strongDM wasn’t founded to help with remote workers forced out of the office by COVID-19. They have been around for five years now. But, the company does excel at allowing you to manage and audit remote access to all of your assets including DBs, servers and clusters (as well as apps and services) anywhere from anywhere.
In this DevOps Chat we speak with strongDM Justin McCarthy, CTO and co-founder about how the company’s technology works and how it is helping companies move to remote access given current conditions.
As usual, the streaming audio is immediately below, followed by the transcript of our conversation.
Transcript
Alan Shimel: Hey, everyone, this is Alan Shimel, and you’re listening to another DevOps Chat.
Really happy to be joined on this chat by Justin McCarthy of strongDM. Hey, Justin, welcome to DevOps Chat.
Justin McCarthy: Hey, Alan — thanks.
Shimel: Pleasure to have you on here, Justin. You know, as we were talking a little bit off mic, I don’t know if we’ve introduced our MediaOps community, meaning DevOps and Security Boulevard and Container Journal, we haven’t introduced strongDM to them before. So, why don’t we start with that, Justin, and if you wouldn’t mind, in telling the story, talk about a little bit about your own personal journey.
McCarthy: Yeah, sure thing. Alright, so, first, I guess I’ll just briefly introduce myself. So, I’m the co-founder and CTO of strongDM. And the product is actually, strongDM itself is the best way to manage and audit remote access to your servers and databases and really even Kubernetes clusters. So, that’s what we focus on. We are a remote access product.
And the way we came to it is basically just a sort of typical startup story. We’ve been around for five years now, and at the beginning, it was scratching an itch just like so many other infrastructure and DevOps products out there. So, in my career, I’d always been involved in growing the teams that built the product and, inevitably, when you build a product and when you ship and when you have production data, you need to grant access to it. To analyze it, you need to grant access to it to administer it, to debug it.
And that process always felt a little bit somewhere between inconvenient and scary, right? [Laughter] And so, basically, strongDM — yeah, is the response to all those feelings of, that it wasn’t quite as smooth as it could be, it wasn’t quite as safe as it could be.
Shimel: Excellent, excellent. And you mentioned the company’s around now about five years.
McCarthy: Mm-hmm.
Shimel: That’s cool. Alright, let’s talk about — and you’re right, a lot of companies do grow out of one particular scratch to itch, and I’ve done my share of startups over the last 25 years. And what generally happens is, you find out that that particular itch may have associated itches, right, and there’s ancillary things — well, once I scratch that itch, the next itch pops up, right? To paraphrase “The Phoenix Project” or something and bottlenecks and the goal.
Talk to us—what’s the itch, and then what have you guys found over the five years about kinda getting to that itch and associated itches?
McCarthy: Yeah, yeah, definitely. So, at the core, the technical approach that it probably takes is that we are an identity-ware proxy, okay? And the first application of that was for database access. So, that’s where we started, right?
Shimel: Mm-hmm.
McCarthy: And in fact, at the beginning of time, we thought maybe that was all there was to it. But as we —
Shimel: Hold on a second, though.
McCarthy: Yeah, sure.
Shimel: So, an identity-ware proxy, primarily for databases. For some of our audiences — our security … actually, our DevOps audience probably gets that, some of our security folks do. But break it down for me, Justin — what exactly do you mean by that?
McCarthy: Sure thing. So, this is an architecture that I think a lot of folks might know as Zero Trust, a lot of folks might know as BeyondCorp, and there were a lot of examples of it out there in sort of an HTTP only case. When we originally conceived of and built the product, it was kind of even prior to a lot of that nomenclature existing.
So, what an identity-ware proxy is, it is a proxy for a given type of service. Let’s continue to use databases as the example. So, if somebody needs to interact with a Postgres database or a Microsoft SQL Server database — so, let’s say Alan needs to connect your local copy of Tableau to one of those systems, right? So, Alan would log into strongDM and then strongDM would then conduct all of the traffic, essentially, forward it to the target systems. And the identity-ware aspect is that, essentially, we know it’s Alan the whole time and we’re proxying that traffic and we’re handling, essentially, all of the routing of that traffic.
Shimel: Got it.
McCarthy: And what’s interesting about that is that you kind of get a lot of the sort of — you get a separation of sort of Alan’s identity from, you know, the credentialing of the underlying system. So, you can actually credential that separately, which means you can rotate the underlying credentials without bothering Alan.
Shimel: Now, in and of itself, can that be a security kinda setting up kinda almost a man in the middle type of situation?
McCarthy: Yeah, so, in a lot of enterprises and environments, you at some point, you have to answer the question, how are we gonna audit this particular traffic stream, right? And so, there are also a lot of products out there that are dedicated to, for example, breaking TLS, right? Being the official man in the middle, right?
Shimel: Yep.
McCarthy: So, our product has an element of that built in, although it’s not a generic TLS breaker. What it is, is it’s a protocol specific way to answer the question, you know, given MySQL database selection, what would you want to know about what Alan did yesterday? And so, our product is focused on extracting that kind of rich information about what Alan did yesterday with respect to this MySQL connection.
Shimel: Sure — great, great. Now, what made databases sort of, you know, the prime example of where to use this or as the first use case?
McCarthy: Yeah, it was the first use case, largely because, again, we were scratching our own itch. [Laughter] So, that was the one that I most often encountered.
Shimel: Okay.
McCarthy: You know, and the appeal is, it’s phrased as, you know, “Can I please have access to this because I need to debug X?” Right? And that always, whoever is saying yes or maybe or no to that request, you know, there’s a lot of hope and trust that when you say yes it’s gonna be okay. So, what our product does is, it takes all that, the sort of emotions around that event [Laughter] and tries to give you an answer for how you make that convenient and how you make that safe for everyone.
Shimel: Excellent, man — good. Alright. So, first ditch is the database and we figure that out and go from there, Justin.
McCarthy: Sure. So, as I’m sure, as you found with many products, you know, why adopt 10 different products when you can get your existing vendor to do one more thing for you and then maybe reduce and concentrate more of your attention on one tool and so, that’s where our customers pushed us. And so, the next very strong demand that we saw was, now that all of our data systems are granted and revoked access through strongDM, could you also begin to do some of the interactive session and shell-based protocols? So, the first two there were obviously SSH and Windows Remote Desktop. So, that’s where we went next.
And the theme, if you can sort of imagine it is, you know, everyone in my organization that maybe has engineer in their title or even analyst or scientist — essentially, all of those folks, they need more than just webpages to do their job, right?
Shimel: They do.
McCarthy: And so, if it were just webpages, then existing single sign-on would work great, right? But since it’s more than that, it’s deeper than that, it’s really that whole collection of use cases that our customers began asking us to take on.
Shimel: Excellent. Good stuff. And so, let’s talk a little bit about — so, how, is this sort of distributed as a SaaS kind of thing or a web-based kinda interface? How does that work?
McCarthy: Sure, yeah. I would say we are neither traditional SaaS, nor traditional on prem. So, in terms of how the product deploys, our customers end up running a bunch of it, but not all of it. So, with any system that involves credentials, any system that involves cryptography, operating it successfully and carefully is actually a huge part of getting it right, okay?
Shimel: Mm-hmm.
McCarthy: So, what we’ve tried to do is, we’ve tried to unify the sort of operation configuration. So, if you think of it like centralizing the policies, centralizing the key management.
Shimel: Yeah.
McCarthy: So, that’s the part that we host. But the part that actually runs the proxies and therefore essentially the actual conduits for all the data, that runs entirely in customer environments.
Shimel: And what kind of environment are you talking about?
McCarthy: Yeah, so, I would say our average customer, the answer is, like, several. [Laughter] So, there are very few environments where you have just one cloud, where you have just one prem data center. So, it ends up actually being several. And so, that’s another strength of our architecture and our approach is that our product, from day zero, was designed with that in mind, so you can run our proxies in Azure and in AWS and in your existing legacy data center. They all unify into one sort of access plane, and it doesn’t matter the product. The same grant access gesture applies to all of those environments.
Shimel: Oh, okay. Very cool. Very cool. And, you know, from what you’re describing, to me, it doesn’t really make a difference whether I’m a cloud native company, let’s call it, right, or maybe an old line company that had my database running in the closet, right? This kind of identity by proxy is still something I can utilize to make my life easier.
McCarthy: Yeah, absolutely. And of course, we would hope that it’s especially suited to a hybrid environment like that, because the ability to, from an end user point of view, from one of your data scientists, they just know the three logical things they need to access to do their job. They definitely don’t care what cloud it’s hosted in. They don’t care what data center it’s hosted in, but from the point of view of that end user, it just looks like one thing.
Shimel: Okay. Now, let’s look at it from the lens of COVID, which we kinda always have to look at everything today through this lens — it seems like this would be a help, right, if I just had to move my whole workforce home, you know, remote. What have you guys been seeing on that?
McCarthy: Yeah, I think our story there is pretty similar to what a lot of companies that are part of the sort of next generation of IT and — we’re sort of seeing the same trend that everybody else, more people moving remove, therefore any remote access products are, there’s a lot more interest at the moment.
So, we were always about granting access remotely. It was always a workforce that was going to be distributed. That was our typical customer, anyway. So, it’s definitely the same theme, but just more than we were seeing pre-COVID.
Shimel: Excellent, man. Now, one thing — it’s funny, I just had a conversation with another company within the IDM space, kind of in like an ED directory service, let’s call it, and this popped up. With the people working from home, with the explosion of how many apps and SaaS services, you know, we’re all accessing right now, it’s great to be able to have just a single proxy, if you will. So, I only have to worry about really going once and then on the back end, it connects to all of these services, let’s call them, or apps.
And so, from my point of view, that’s a great thing. From your point of view, Justin, right, now you’ve gotta hook into all of these different, new apps and services. How do you do that? Is that via API? Is it a one-off for every one you’ve gotta go into? You know, what’s involved there if I bring you — you know, some app you guys haven’t encountered before?
McCarthy: Yep, sure. So, I do, there is an important distinction here. There’s a generation and a category of products that you might call them cloud brokers, right? So, cloud access security brokers, that category where you have a workforce that needs to access Salesforce, needs to access another SaaS application. We consider that sort of part of the market to be something that’s necessary but not our specialty.
Shimel: Not your place.
McCarthy: Yeah. So, our specialty is, again, it’s that staff where there’s probably an engineer or somehow technical, there’s a technical name in their role somewhere, and they need access to things that aren’t webpages. And so, for that, the procedure is — hey, I’ve got this maybe let’s say even legacy database or I’ve got this type of terminal access that we do that, let’s say we’ve got a lot of machines that are connected via VNC or something. So, and let’s say that’s not on our official supportive protocols list yet. It’s as simple as, we do an intake, we understand the protocol, we add it to the product — that’s it.
Shimel: Okay. So, you guys do that. I don’t do that myself. I don’t have to kinda write to an API or something and make —
McCarthy: Yeah, no, exactly. Any system that feels like any sort of client server access paradigm, we can model it in our, essentially in our platform, and then begin granting access to it.
Shimel: Okay. Almost out of time, Justin. One more area I wanted to hit on this one, though, and that is — talk to me about what to set up here, right? Whether I’m doing it on the cloud, prem, a little of both — how big a job is it to get this thing up and running?
McCarthy: Yeah. So, we also, of course, have the advantage of — like I said, we’re five years old, but that means we’re only five years old. [Laughter] So, we knew it had to be easy, right? Yeah.
So, yeah, the act of deploying our proxies is essentially roughly turning it on. Because what then the proxies do is, they take over, for example, topics like discovery. So, they discover what host names they can access and they begin exposing it back to it in the administrative console. So, that’s the one aspect that, you know, deploying it is pretty much turning on the software.
Additionally, because so many of our customers rely heavily on automation for their DevOps, another way to think of it is, if you already have, if you already have a great Terraform setup that you’re happy with, you have a great cloud formation setup that you’re happy with, we are gonna integrate natively with that setup as well. So, it’s going to be, you’re essentially the overlay, your proxy overlay on your existing infrastructure is gonna go in and it’s gonna feel exactly like anything else that you’re familiar with deploying via Terraform or inside your Kubernetes cluster, for example.
Shimel: Perfect, man. All good stuff. Justin, I promised you we were gonna do 15 minutes, but I blew it — but not too bad. We’re not too bad. Well, we’re gonna have you back on. It’s gonna be a little bit of a continuing series, right? So, look forward to our next conversation.
You know what I realized? We didn’t even mention the website, though. So, for people who want more information, it’s strongDM, S-T-R-O-N-G-D-M-dot com, right?
McCarthy: Yep.
Shimel: And then can get, if they wanna go check stuff out there. And we’ll have you back on real soon and continue this, man. Sounds great.
McCarthy: Great. Alright, thanks a lot, Alan.
Shimel: Alright. Justin McCarthy, CTO and co-founder of strongDM here on DevOps Chat. Hey, this is Alan Shimel, and you’ve just listened to another DevOps Chat.
