At Cloud Native Security Con, we sat down with Solo.io's Marino Wijay and Jim Barton, who discussed how service mesh technologies have matured, especially now with the removal of sidecars in Ambient Mesh that it developed with Google. Ambient Mesh is "a new proxy architecture that, according to the Solo.io site, "moves the proxy to the node level for mTLS and identity. It also allows a policy-enforcement policy to manage Layer 7 security filters and policies. A sidecar is a mini-proxy, a mini-firewall, like an all-in-one router, said Wijay, who does developer relations and advocacy for Solo. A sidecar receives instructions from an upstream control plane. "Now, one of the things that we started to realize with different workloads and different patterns of communication is that not all these workloads need a sidecar or can take advantage of the sidecar," Wijay said. "Some better operate without the sidecar." Marino Wijay - @virtualized6ix Jim Barton - @jameshbarton Alex Williams - @alexwilliams The New Stack - @thenewstack
At Cloud Native Security Con, we sat down with Solo.io's Marino Wijay and Jim Barton, who discussed how service mesh technologies have matured, especially now with the removal of sidecars in Ambient Mesh that it developed with Google.
Ambient Mesh is "a new proxy architecture that, according to the Solo.io site, "moves the proxy to the node level for mTLS and identity. It also allows a policy-enforcement policy to manage Layer 7 security filters and policies.
A sidecar is a mini-proxy, a mini-firewall, like an all-in-one router, said Wijay, who does developer relations and advocacy for Solo. A sidecar receives instructions from an upstream control plane.
"Now, one of the things that we started to realize with different workloads and different patterns of communication is that not all these workloads need a sidecar or can take advantage of the sidecar," Wijay said. "Some better operate without the sidecar."
Ambient Mesh reflects the maturity of service mesh and the difference between day one and day two operations, said Barton, a field engineer with Solo.
"Day one operations are a lot about understanding concepts, enabling developers, initial configurations, that sort of thing," Barton said. "The community is really much more focused and Ambient Mesh is a good example of this on day two concerns. How do I scale this? How do I make it perform in large environments? How can I expand this across clusters, clusters in multiple zones in multiple regions, that sort of thing? Those are the kinds of initiatives that we're really seeing come to the forefront at this point."
With the maturity of service mesh comes the users. In the context of security, that means the developer security operations person, Barton said. It's not the developer's job to connect services. Their job is to build out the services.
"It's up to the platform operator, or DevSecOps engineers to create that, that fundamental plane or foundation for where you can deploy your services, and then provide the security on top of it," Barton said.
The engineers then have to configure it and think it through. "How do I know who's doing what and who's talking to who, so that I can start forming my zero trust posture?," Barton said.
Alex Williams 0:08
You're listening to the new stack makers, a podcast made for people who develop, deploy and manage at scale software. For more conversations that articles go to the new stack dot I O. All right now on with the show.
Colleen Coll 0:32
Solo dot i o the modern API infrastructure company delivers application networking, from the edge to service mesh, enabling enterprises to adopt secure and operate innovative cloud native technologies.
Alex Williams 0:49
Hey, everyone here at the cloud native security show in Seattle. I'm here with the folks from solo.io Rena J. Developer Relations and advocacy at Zillow. Hey, Maria, how are you? Hey, how's it going? Good. And Jim Barton field firstname.lastname@example.org. Hey, Alex, good. Spend
Jim Barton 1:07
some time with you today. Well, good to spend
Alex Williams 1:09
some time with you. So we're just talking return about trained professionals? We're trained professionals here. Right? Right. Right, you can absolutely say with confidence, how much of a professional do you have to be these days to use a service mesh? Is it as complicated as crazy as it used to be?
Marino Wijay 1:26
Well, I'm not ready for that.
Jim Barton 1:30
So yeah, there's no question there are challenges to configuring service meshes along with a lot of other cloud native technologies. It's definitely one of the things that that we see in the in the service mesh community in the SEO community, specifically, where we're working really hard to do things to make it simpler, both from a from a setup configuration standpoint, as well as from an operational standpoint.
Alex Williams 1:52
So let's get into that a little bit. Because let's talk about the basics of a service mesh that, so what are the basics these days? And my question really, is, it communicates between services. But how does it do that? And why is it important?
Marino Wijay 2:06
Yeah. So there are a few things that we really look for when we're building out our applications. And when we try to run them in production, we want to see how they're doing. We want to see how we can connect to them. And we want to make sure that we can secure them. It's simple as that. But how do you achieve that you can't just simply turn something on and expect that to just suddenly work. And so this is where something like a service mesh might come into play here, where it gives you the capabilities to say, hey, this service can talk to that service, I can see what the service is doing. I can control and say no, you can't do that to that service. And that just maps to those key tenants I just suggested. So then how
Alex Williams 2:45
does that embody the principles of zero trust? And especially kind of concerning SEO, which is a service mesh framework?
Jim Barton 2:52
Sure. I mean, the primary tenant of zero trust is trust no one, right? Assume the attacker is already in your network. And so service mesh technology is to specifically makes it easy to specify policies in a declarative fashion that will apply across, you know, a whole suite of applications that are that are running within a mesh.
Alex Williams 3:10
So this is something that makes me a head scratcher a little bit. If there's already an intruder inside the building, then isn't the problem, how they got into the building in the first place.
Jim Barton 3:21
So definitely defense in depth is a principle of security that I think a lot of organizations are looking to, to implement more completely. I know, I was part of an organization, which I won't mention on camera that had an intruder in the building, so to speak. And it was it led to a huge engineering effort that took place over probably the next 18 months to try to shore up internal systems that actually did not have that working assumption, right, that we need defense in depth that perimeter security was enough. And in fact, in many cases, it's not. You know, we do need to have security at the perimeter, certainly, but also security within the mesh of applications that we're operating as well.
Alex Williams 4:01
So is it for that developer? Is it for the dev SEC ops Pro? Is it for all the above?
Marino Wijay 4:08
I would say it's for the dev SEC ops professional primarily because a developer is not there to care about how do my services connect, they're there to build, they're there to create something. It's up to the platform operators or engineers or dev SEC ops engineers to to create that fundamental plane or foundation for where you can deploy your services to, and then provide the security on top of it. And then they have to configure it, they have to sit there and think about how do I how do I profile this? How do I know who's doing what and who's talking to who, so that I can start forming my zero trust posture? I think
Jim Barton 4:41
Marino makes a great point. I want to just add on to that a bit. So one of the things that I've seen my history in the industry is that a lot of times where ideally you do want to have a platform team that has ultimate responsibility for those things. Oftentimes, it does, at least in my experience, fall on developers who end up you know You know, owner of application a ends up solving the problem this way, application B solves it a different way, and so forth. And so you end up with this hodgepodge of solutions, quote, unquote, that don't really solve the problem at an enterprise level. And I think that's really one of the key values of service mesh, we frequently will see people who come to us and like, I have a security mandate, maybe from some regulatory agency, or perhaps a government agency that requires me to certify, right that I have a zero trust security posture. And that's really where it's at. That's
Alex Williams 5:35
solo.io has its sweet spot. Exactly. That's regulated companies. And, you know, I have in my notes about MTLS. Yeah. And the importance of that, and that relates kind of this conversation doesn't really interesting,
Marino Wijay 5:48
let me, let me take you back in history a little bit, right. So they're about 1015 years ago, we wanted to encrypt our communications, we wanted to secure our networks. And so we would use VPN technology to be able to do that IPsec happens to be one of the more notable technologies out there. But in a fundamentally did something it encrypted, the data path. Now today, we kind of needed that similar capability, but much more automated, much more tunable towards smaller components, smaller pieces of our software. And so the other thing we also had to consider was while we encrypt our communications, we also have to build in trust, how do we make sure that I can trust you, and you can trust me. And so this this concept of mutual TLS, or mutual Transport Layer Security came about so that we can effectively create that secure data path, and then authorize who you want to talk to? Who
Alex Williams 6:37
authorized who you want to talk to? Yeah, okay. And that's kind of one of the core aspects of service mesh is that it then authorized, who you can talk to
Jim Barton 6:44
correct. And to be able to do that in a repeatable policy driven fashion, right, not depending on individual application owners, to divine what the enterprise requirement is, and then to go implement that on their own, but to be able to manage that from a dev SEC ops platform, and to do that in a declarative repeatable fashion. And
Alex Williams 7:03
that's where it kind of comes in to service communication. So those permissions for each service to talk to each other.
Marino Wijay 7:10
Yes, precisely. And you would you would basically start off with a allow nothing, and then you would incrementally allow things to start talking to each other. You take the the approach of least privilege, right. Yeah, exactly. Yeah.
Alex Williams 7:21
Which we were talking about earlier a little bit earlier. Right. So then, when you look at that, you know, there is this new capability that you're offering called Ambien match. And I'm curious about what is Ambien mesh? Why do you get developed? And really, what are its implications for service mesh? Sure. So
Marino Wijay 7:39
Ambien meshes and interesting mode of the service mesh Sto. And how it came to be is quite interesting. But let me first back up a bit and talk about this very interesting component called the sidecar. When you deploy a service mesh, every service or application gets something called the sidecar resource, which is basically a mini proxy, mini firewall mini router all in one. And it's receiving instructions from an upstream control plane. Now, one of the things that we started to realize with different workloads and different patterns of communication is that not all these workloads need a sidecar or can take advantage of the sidecar. Some better operate without the sidecar. And so we decided to take this approach in the sto community to say, hey, we still want service mesh like functionality. But how do we provide that if we don't have a sidecar, enter ambient mesh, where we move away the sidecar functionality to components that live more higher up in the stack inside of the environment that we operate in. And so that way, we can still take advantage of the mesh functionality without necessarily having to deploy this sidecar. But one of the other things, too, is that with a sidecar resource, you're consuming resources, you're having to impact workloads and how they operate, you're having you're having to inject and modify an actual workload to make this possible. With ambient mesh. That's not the case anymore.
Alex Williams 8:58
Okay. And so, I have heard criticism of the sidecar because it's a little bit complicated, right? And someone tried to explain the concept to me before and on site, cars in house, essentially, kind of like putting all your furniture outside of your room and then putting it back into your room. Houses lie I, I clearly, am not a sidecar knowledgeable guy.
Jim Barton 9:23
I think basically, one interesting way to look at it is you have all of these cross cutting capabilities that need to operate across the independent of applications, right? Every application needs to be able to enforce security. Every application needs to be observable at some level, you know, within all applications, you need to be able to route traffic in one way or another. And so, you know, what are your choices, right? You can either go and have each application, implement kind of the undifferentiated, heavy lifting associated with those policies or you can outsource that but your furniture outside your apartment if you will. or you can outsource that to a service mesh. And that's one of the real fundamental values of SEO, in general, is the ability to take those cross cutting concerns that everyone has. And to be able to outsource that to a, you know, declarative repeatable policy driven service mesh. So where
Alex Williams 10:17
are we now then was service mesh? Do you think it's in maturity? I've heard it being discussed with observability, for example.
Marino Wijay 10:26
Yeah, so in terms of maturity, right now, the ecosystem has grown substantially. And there's a lot of consumption, I mean, effectively, a lot of environments that are using service mesh, specifically sto in production. And they've started to realize limitations of having to manage sto on its own. And so we're here to help with that with our glue platform to provide simpler ways to operate it. So you mentioned something about observability as well, that has matured primarily because while sto and service meshes offer up that observability point, we needed better ways to manipulate that data and see what's doing what we needed better telemetry around our applications. And so we partnered with other open standards, like open telemetry, and maybe Jim, you might want to expand on a little bit more of that observability
Jim Barton 11:13
Sure, I think, you know, observability is key, not only from the standpoint of just being able to know what's happening within my service mesh, being able to debug when I have problems and that sort of thing. But even from a security standpoint, right? Just being able to know, okay, here's a pattern of behavior that I haven't seen before. From a security standpoint, perhaps a lot of requests are now being rejected due to some due to some condition that I don't completely understand. And so having access to, to the metrics and the tools that let you drill into those and really get deeper insights into why are these security policies suddenly firing hard, this swath of requests, suddenly failing? is a real key value for service meshes in general.
Alex Williams 11:57
So what are some of the limitations of service mesh that you hope to have are common in the next 1218 months? I like to make up my final question.
Marino Wijay 12:07
So the current limitations really come down to not the actual system itself. It's what you do with it. And it really comes down to scale and automation. So you could definitely use a service mesh from the open source world, but you're gonna run into your own challenges of having to manage this at scale, having to make changes whenever, you know, you grow your own personal environments, or you grow your workloads or add more workloads and you're trying to add in levels of higher levels of availability, or trying to achieve things like disaster recovery, or avoidance. Jim, I don't know. So
Alex Williams 12:39
like, I guess the question to that is, does that mean service mesh is fully built out? fully mature in the core?
Jim Barton 12:45
That's a really good question. Let me bounce off of what something Marina was saying. We'll come back to that. I think, if I had to characterize what's going on in the community right now, with respect to maturity, it's the difference between day one operations and day two operations, right? Day one operations are a lot about understanding concepts, enabling developers initial configuration, that sort of thing. The community is really much more focused and Ambien mesh is a good example of this. On day two concern, how do I scale this? How do I make it perform in large environments? How can I expand this across clusters and multiple zones in multiple regions, that sort of thing? Those are the kinds of initiatives that we're really seeing come to the forefront at this point.
Alex Williams 13:27
Well, thank you both for taking some time to talk here. Really.
Jim Barton 13:31
Thank you. Thank you, Alex. Appreciate it.
Marino Wijay 13:32
Thank you very much for the time.
Colleen Coll 13:35
solo.io the modern API infrastructure company delivers application networking, from the edge to service mesh, enabling enterprises to adopt secure and operate innovative cloud native technologies.
Alex Williams 13:51
Thanks for listening. If you'd like to show, please rate and review us on Apple podcasts, Spotify, or wherever you get your podcasts. That's one of the best ways you can help us grow this community, and we really appreciate your feedback. You can find the full video version of this episode on YouTube. Search for the new stack and don't forget to subscribe so you never miss any new videos. Thanks for joining us and see you soon.
Transcribed by https://otter.ai