Service Meshes and Application Security – Brian Gracely, Solo.io

This is Textron TV. Hey guys. Thanks for the thrill.

io. And we're talking about security and service meshes and how the whole landscape is starting to change under our feet arguably for the better Brian. Welcome the show.

Hey, Mike great to be with you today. We've been talking about service meshes a lot in the context of API management and some people see it as a way to provide a higher level of abstraction above the network layer and then has a lot of promise for making networking simpler. But I think we've been overlooking the security aspects of this.

So maybe you kind of want to walk us through with from your perspective. How does all this changing application networking landscape improve the overall state of cyber security? Yeah, I think it's um, I think it's a great topic because service meshes sort of it's sort of always gone back and forth between being is it a silver bullet for cloud native or is it you know, is it is it sort of hard or misunderstood?

And I think what what what's an interesting discussion is, you know, like you said, it's it's an interesting technology for abstracting the network. It's an interesting technology for, you know, helping to manage apis, whether they're sort of internal for microservices or external as sort of an API Gateway, but what's interesting is I think more than anything people end up initially using service mesh as a security capability, right they look at it and they say, you know, From an infrastructure perspective platform engineering perspective, you know, what can we do to make sure that that first and foremost we can internally deliver zero trust we can sort of know what's coming onto the network. We can authenticate things whether those are services or machines.

And so it's it's probably something that we haven't talked enough about just kind of the the raw ability to take, you know, core Primitives of service mesh of things like istio and make them sort of the first step in that zero trust conversation. And part of the issue I think is with zero trust. We assume that the conversations all about trusting end users when in fact, we need to trust microservices apis and tire applications.

So do you think we're not thinking through this whole conversation deeply enough? Well, I think zero trust is one of those terms that that can mean a lot of things to a lot of people so you're right. The first thing we think about is, you know, we used to have we used to have perimeters so we would have vpns and and we would think about you know user authentication or maybe you know, laptop authentication, but what we see, you know, the other part of it and this this really plays to the the concept of defense and depth right?

There's not sort of one Silver Bullet, you know, especially in a microservices world, you know a machine we may need to authenticate a machine. We may need to authenticated virtual machine. It could be a container and a kubernetes world word could be a service and I think you know in the world where we live from from a solo perspective.

To smash. It's really those things that we think about from from a zero trust perspective. So same way that you think about, you know, authenticating a user.

Yeah. It's it's as important to be thinking about you know, how do I how do I authenticate and encrypt and validate a service or a machine or anything along those lines? Is there some sort of aha moment that somebody has and figures all this out or is this more like a byproduct of my initial investment in the service mesh, and then I discover all these downstreams Security benefits.

I think I think what we see in terms of aha moments is is usually two things that the first one is a lot of times. They just assume that kubernetes has all these built-in security things for them and then they start figuring out like, okay, where is where are those things that do, you know Mutual TLS. And and they you know, you start to realize like okay kubernetes doesn't do everything.

You know, it's it's sort of scoped for what it does. And then I think the other sort of aha moment people have is especially in kubernetes environments. Once they start kind of getting past that first project.

So they built out a cluster that first project was reasonably successful and they they go tell their teams. They go tell their boss. Like hey, we were able to deploy faster we were able to scale in new ways.

We couldn't do it before and other teams go. Okay cool. We'd like to we'd like to get those benefits too and and all of a sudden they and you know, the kubernetes team goes.

Okay, great, you know bring bring what you're working on to our environment and and they don't know that team right that that team maybe is it's a different internal team. It could be, you know set a contractors they have it could be, you know, a third party company they're working with and all of a sudden they go. Oh hold on the known environment that I had introduces these variables these unknowns, especially from a security perspective and they start coming around and going.

Okay. I've got a I've got to figure out how to deal with that. So it's usually one of those two moments that that kind of triggers them to go.

Okay, I got to figure out what service mesh can help me with for security. Do you think that this will help narrow The Divide between security teams and developers because in many ways if I'm the development team and I lead the charge on the service mesh. I will have addressed many of the security issues and those guys may not come knocking on the door until after I've already deployed my third or fourth cluster, right?

Yeah, I think what we find is the you know, sort of the platform engineering teams the teams they're running kubernetes again sort of this this Venn diagram of of devops titles SRE titles and maybe Cloud platform titles, you know, the things that we're now kind of lumping into platform engineering they tend to be the ones who, you know, recognize the need for service mesh essentially from a security perspective and and oftentimes they're the ones who, you know kind of realize okay, I you know, I can use even half the capabilities of what service mesh does to to provide an environment that the developers then don't have to care about zero trust they don't have to care about is my service authenticated. It's just kind of taking care of for them. So I think we've seen is is more of an acceleration when when the platform engineering team is is driving things.

Then when the application teams are saying, okay. I have to think about this as a trade off of do I write code do I not write code? Am I going to coordinate all the different teams and all the different languages, you know, when platform engineering or again, you know cloud cloud platform, whatever whatever your organization calls it when they drive it they can just sort of make it a checkbox, you know, do you want your environment secure or you know zero trust doesn't need to be encrypted and and they can kind of be a universal checkbox regardless of your writing code this way using a different language you come on on day one or you come on on day 200, whatever it might be.

As part of that transition I think early on we might have seen service meshes adoption driven by developers. But are we seeing this as part of a shift where we're more Engineers are driving the conversation on the back end and then we're starting to see all these interesting benefits around security and networking that developers may not have initially appreciated. Yeah, I think.

I the way I tend to explain it is we've gone through a couple of different a couple of different Cycles. So what I the way I tend to frame it is we went through a series of time when developers said I'm gonna build applications differently. I'd like to start using containers and and you know, the IT team the platform engineering team basically said, okay.

I've got a respond to that. I've got to give you an environment that's going to do that. They typically were we're picking kubernetes.

0 and that that process for most organizations would take 18 months 24 months sometimes to figure out how do I containerize an application? How are we going to do this? How do we operationalize kubernetes?

And what they're now running into and this is where we're really I think seeing the shift to the problem kind of falling on platform engineering as opposed to the developers is they're now moving into multiple clusters trying to scale environments. And and so the problems become you know, how do I scale? How do I secure multiple environments or multiple teams?

You know, how do I manage those and those tend to fall more on platform engineering because the the application teams have said, okay, we figured out microservices a little bit. We figure out containers are part of the the problem is sort of done and and you know, the other part of the burden has fallen more on the on the infrastructure and operations and clouds team. So I think we have seen a shift of who's more interested in service mesh and and that sort of the tears of service mesh that make are more relevant to the security and operations team become, you know, really really important especially again in that sort of cloud native to Stage where they're trying to scale.

They're trying to to do things that have you know bigger environment. They're trying to bring on more teams. It becomes really important, you know, almost more so important for them than any individual application team.

We used to have fairly clear swim lanes for people. They were networking people's security people developer folks. Do you think that you know much like any other kind of democratic system?

This is starting to get a little more Messy as it becomes more of a team sport. Well, it's you're right we and we talk about that quite a bit that it was sometimes life was easier when you just talked to the database team or the network team. I think at the end of the day.

Those those silos kind of went away because the the business goal or the business driver was were you know, our experience is a business our experience with our customers are digital and and our customers are expecting more out of that digital experience than they were when it was a physical store or it was a you know, physical hospital or whatever it might be. And so ultimately what happened was that that need to build a better digital experience with your customers to be able to to evolve it quickly kind of said look we'll never get there with the existing it silos. And so, you know, it was it was out of necessity that these teams kind of came together.

They couldn't live by, you know, open a ticket and wait a couple of days for this team to do it and open a different ticket for the other team to do it. So I I think you know, especially around the digital experience stuff whether we call it digital transformation or you know, again building more modern Cloud applications. There's no way to go back to those old Sil Right the teams the network team the infrastructure team the security team, you know the team that does, you know builds and cicd.

They have to be one team at this point. There's no other way to drive velocity that the business needs in terms of those digital experiences. So bringing it full circle as we look at Cloud native and microservices are the bad guys discovering these as a tank vectors or they start in a Zone in on the apis that each of these microservices expose.

I mean how good are they getting? Well the best the bad guys always have the advantage because you know, they need to just have one good day. Whereas, you know, the quote unquote good guys, you know need to have everyday be a good day.

So, you know that that's always been the equation. I think you know, the the one thing that's really accelerated over the last two or three years three or four years is, you know, in the early days of cloud native in the early days of kubernetes. We tried to apply a lot of the kind of the older static security principles to what we did right perimeter-based security, you know not being able to sort of dynamically scan code that was coming off the internet or off of Docker Hub.

So the industry's gotten much much better realizing like this is what this new world looks like and I think what we're what we're now kind of, you know figuring out and we've been figuring out for the last couple of years is what is that new more Dynamic defense and depth really look like because you know the same Principles of defense and depth are are extremely appropriate in this space. Right? It's it's never going to be one server full Silver Bullet in terms of you know, perimeter security or scanning technology or any of those things, but I think it's you know, it's also, you know, we've been figuring out how do we apply more modern Technologies?

So things like, you know, the filtering Technologies and envoy can be applied both in service mesh as well as API Gateway. So we're seeing some reuse of technology that can be applied in multiple locations. And then we've seen the industry be, you know, very very good about you know, applying good principles and new technologies to this sort of new world.

So yeah, the bad guys are always going to be out there, you know, they're they're going after apis more than they ever have and in some of those cases. It's it's really important to say like look the way that we thought about stuff four or five years ago probably isn't necessarily going to be appropriate the scale that we need the ability to run things natively in the Loud the ability to be in Native with the other automation that you do with kubernetes those become equally as important as just do I have the right, you know pure point in time security technology. So I'm bringing Full Circle.

We have seen the emergence of saying site reliability Engineers over the years and there's different Engineers for different things. So do you think we'll see a security engineer become part of the devops process and they'll be Specialists that kind of are the people that everybody else leans on to kind of drive this process. Yeah, I think we've we've seen you know, we've seen a push from kind of the early adopters where you know, there's there's a couple of terms to get used all the time.

You know, one of them is is shift left. So if we think about sort of a left to right, you know, orientation of of how an application goes from being developed sort of left to right through the pipeline and testing process all the way into production. You know, what we've seen is people Shifting the security functionality left.

So it's not it's you know, it's it's not the the application got built. We throw it over the wall to production and I hope security, you know raises a red flag. If it's bad we're seeing more and more security functionality again sort of in that Dev SEC Ops mindset be pushed left.

We're seeing security embedded in you know, how things are developed how things are tested in the pipelines. You know, we're seeing security being part of kind of the deployment models. So yeah, I think we're We've begun to see that not everybody obviously is as kind of gotten to that point yet, but we've seen enough best practices that you know, whether you can again whether you call it shift left in terms of Shifting your security capabilities further into the development and testing process or you just sort of start thinking about you know devsecops is being a core element of that that platform engineering piece, you know, it's definitely something that a lot of people are talking about.

The capabilities are out there and you know, those those people are you know as important as they've ever been if not, you know, maybe more so now just the amount of change the amount of speed that's happening in the application development. All right, folks you've heard the phrase security is everyone's job what perhaps the best place for everyone to get started in the same page is with the service mesh. Hey Brian.

Thanks for being on the show. Thanks Mike. Appreciate it.

All right back to you guys in the studio.