EP 286: Make Work-From-Home Easy as Pie w/ StrongDM

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.

Hey, Alan, thanks. Pleasure to have you on here, Justin. You know, as we were talking a little bit off off mike, I don't know if we've introduced our MediaOps community, meaning, DevOps, Security Boulevard, all of our Container Journal.

M. 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. Yes, sure thing. All right.

So first, I guess I'll just briefly just introduce myself. I'm the co-founder and CEO of Strong GM. The and the product is actually strontium itself is is the best way to manage an audit.

Remote access to your servers and databases and really even Kubernetes clusters. So that's that's why we focus on we are a remote access product. And the way the way we came to it is basically just sort of typical startup story.

We've been around for five years now. And at the beginning, it was it was scratching. And it's 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 that built the product. And inevitably, when you build a product and when you when you ship them, when you have production data, you need to grant access to it, analyze it, to grant access to it, to administer it, to debug it. And that process always felt always felt a little bit somewhere between inconvenient and scary.

Right. And so so basically strong. Yeah.

Yes. Is the response to all all those feelings of it. But it wasn't it wasn't quite as smooth as it could be.

Wasn't quite as safe as it could be. Excellent. Excellent.

And you mentioned the companies around now about five years score. All right. Let's talk about.

And you're right, a lot of companies do grow out of, you know, one particular scratched edge. 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 these ancillary things will once I scratch that edge, the next itch pops up. Right.

And to paraphrase like the Phenix project or something and bottlenecks. And we go talk to us. What's the itch?

And then what have you guys found over the five years about kind of get to that itch and associated itches? Yeah, yeah, definitely. So at the core, the technical approach that our product takes is a we are an identity aware proxy.

OK. And the first application of that was for database access. So that's where we started running.

And in fact, at the beginning of time we thought maybe that was all there was to it. But as we as a. That is not the answer.

So an identity aware proxy primarily for databases. For some of our I was security audit, we actually I DevOps audience probably gets that some of our security folks to break it down for me. Justin, what exactly do you mean by that?

Sure thing. So this is this is an architecture that I think a lot of folks might know as zero trust, a lot of folks might know as beyond Corp. And there are a lot of examples of it out there in sort of an age GDP only case when we originally conceived of and built a product.

It was kind of even prior to a lot of that. No. One culture existing.

So what would an identity aware proxy is, is. It is a proxy for, you know, a given type of service. Let's let's continue to use databases as the example.

So if somebody needs to interact with Post Chris database or a Microsoft SQL Server database, so let's say Allen needs to, you know, connect your low copy of Tableau to one of those systems. Right. So Allen would log in a strong VM and then strong VM would then conduct all of the traffic essentially forward to the target systems.

And the identity where aspect is that essential? We know it's Allen the whole time and we're proxy in that traffic and we're handling essentially all of the routing in that traffic. It's interesting about that is that you kind of get a lot of the sort of you get a a separation of sort of Allans identity from, you know, the credentialling, the underlying systems.

You can actually credential that separately, which means you can rotate the undergrad underlying credentials without bothering Allen. Now. In and of itself, can that be a security kind of setting up a can of worms man in the middle type of situation?

Yes, you know, in a lot of enterprise environments, you at some point you have to answer the question, how are we going to audit this particular traffic stream? Right. And so.

So there are there are also a lot of products out there that are dedicated to, for example, breaking. Tell us. Right.

Being the man in the official man in the middle right now. So our our product has an element of that built in, although it's not a generic tearless breaker. It what it is, is a it's a protocol specific way to answer the question.

You know, given given I ask you, well, database system, 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, you know, this my school connection. Sure.

Great. Great. Now, why wouldn't want me.

Sort of. You know, the prime example of where to use this is the first use case. Yeah, it was the first use case largely because, again, we were we were we were scratching our on edge.

So it was. So that was that was the one that I most often encountered. And in.

And the appeal is it's phrased as, you know, can I can I please have access to this because I need to debug X. Right. And and and that always whoever is saying yes or maybe or no to that request, you know, there's a there's a lot of like, you know, hope and trust that when you say, yes, it's going to be OK, what our product does is takes out.

That's the sort of emotions around that event and tries to give you an answer for how to how you make that convenient, how you make that safe for everyone. Excellent. Good.

All right. So first, which is the database, and we we figured that out and go from there just to make sure. So so as I'm sure as you find with many products, you know, why, why why adopt 10 different products when you can get your your existing vendor to do one more thing for you and then maybe maybe reduce and concentrate more of your attention on one tool.

And so that's what our customers pushed us. And so the next very strong demand that we saw was now that, you know, all of our data systems are granted and revoked access through strong data. Could you also begin to do some interactive session and shell based protocols?

H. and Windows Remote desktop. So that's that's where we went next.

And the theme, if you if you can sort of imagine it, is, you know, everyone in my org that maybe has engineer in their title or even analyst or scientist essentially all all of those folks, they need more than just Web pages to do their job. Right. And so if it were just Web pages, then, you know, existing, saying a single sign and we were great.

Right. But since it's more than that, it's deeper than that. It's really that whole collection of use cases that that our customers began asking us to take on.

Excellent. Good stuff. And.

So let's talk a little bit about. So how is this sort of sad distributers, SAS kind of thing or, you know, Web based kind of interface? Sure, sure.

Yeah. I would say we are we are neither traditional SAS nor traditional on Prem. So in terms of how the product deploys our customers and running a bunch of it, but not all of it.

So so with any, with any system that involves credentials, any system that involves cryptography, operating it successfully and carefully is is actually a huge part of getting it right. So what we've tried to do is we've tried to unify the sort of operation and configuration. So if you think of it like the centralizing the policies, centralizing the key management.

Yeah. So that's that's the part that we host. But the part that actually runs the proxies and therefore, you know, essentially the actual conduits for all the data that runs entirely in customer environments and what kind of environment you're talking about.

Yes, so I would say our average customer, the answers like several, so there are very few environments where where you have just one cloud, where you have just one on Prem Data Center. So it so it ends up it ends up actually being several. And so that's another strength of our architecture.

And our approach is that where are our product from? From day zero was designed with that in mind. S.

and in your existing legacy designer, they'll unify into one sort of access plane. And it doesn't matter the product. You're the same grants, access gesture applies to all of those environments.

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. A cloud native company, let's call it, right.

Or maybe an old line company that, you know, had my database running in the closet. Right. I mean, this this kind of a, you know, identity by proxy is still a.

Something I can utilize to make my life. Yeah, absolutely. And of course we would.

We would we would hope that it. It's especially suited to a hybrid environment like that, because the ability to from an end user point of view, from what are your data scientists, you know, they 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 at one thing.

Ok, now let's. Let's look at it from the lens of Kofod, which we kind of always have to look at everything today through this lens. It seems like this would be a help, right?

If if I just move my whole workforce home remote, how it would work. What do you guys have been seeing on that? T.

and and we're we're sort of seeing the same trend that it feels more. More people moving remote. Therefore, any remote access products are ah, there's a lot more interest at the moment.

So so we we were always about granting access remotely. It was always a workforce that was going to be distributed. That's that's that was our typical customer anyway.

So it's it's definitely the same theme, but just more than we were seeing free of it. Excellent. Now, one thing I it was funny.

I just had a conversation with another company in the IDM space came in Lincoln EDI's directories service. Let's call it. This popped up with do with the people working from home.

With the explosion of jobs, how many apps and sassed services were all accessing right now? It's great to be able to have, like, 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 got to hook into all of these different new apps and services.

How do you do that? Is that like the API? Is that a one off for everyone?

You've got to go into, you know what what what's involved there. If I bring you some app you guys haven't encountered before yet. Sure.

So. So I do. There is an important distinction here.

There's a there's a generation category of products that you might you might call them cloud brokers. Right. So cloud access already brokers that that that that category where you have a workforce that needs to access Salesforce needs to access another SAS application.

And we consider that sort of part of the market to be something that's necessary but not are not our audience. Yeah. So our our specialty is again, it's that staff where there's probably engineer or somehow technical.

There's a technical name in their role somewhere. Right. And they need access to things that aren't Web pages.

And so and so for that, the procedure is, hey, I've got this maybe let's say even legacy database where I've got this type of terminal access that we do that, you know, let's let's say we've got you know, we've got a lot of machines that are connected to be a fiancee or something. So so and let's say that's not our official support per calls list yet. It's as simple as we do an intake.

We understand the protocol we added to the product. That's it. Ok.

So that you guys do that. I don't do it myself. I don't have the right kind of right to an API or something.

Yeah, exactly. Any any any system that that feels like any sort of client server access paradigm. We can we can model it in our essentially in our platform and then begin granting access to almost out of time just then.

One more area. I want to go ahead on this one now, and that is talk to me about what? To set up here, right?

Whether or whether I'm doing it on the cloud. And a little of both. How how how big a job is it to get this thing up?

Right. Yeah. So we also, of course, have the advantage of flying.

And like I said, we're we're five years old, but that means we're only five years old. So. So we knew it had to be easy, right?

Yeah. So. So, yeah, the the 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, they discover what names they can access. And they begin exposing it back to the administrative council. So that's 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 set up, they're happy with. You have a great information set if you're happy with. We are going to integrate natively with that setup as well.

So it's going to be your your essentially overlay your proxy overlay on your existing infrastructure is going to go in and it's going to feel it's going to feel exactly like anything else that you're familiar with, deploying the term form or inside your current cluster, for example. Perfect. Well, good stuff.

Justin, I promise you, we're going to do fifteen minutes, but I blew it. Not too bad. We're not too bad.

But we're gonna have you back on. It's going to 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 Web site, though.

So for people want more information. It's strong. M.

as Tiaro and G. D and dot com. Right.

Yes. And they can get if they want to go check stuff out there. And we'll have you back on your soon to continue this spin.

Sounds great. All right. Thanks.

Thanks a lot. All right. Justin McCarthy, CTO, co-founder of StrongDM.

Here on DevOps chat. Hey, this is Alan Shimel. And you just listened to another DevOps Chat.