EP122 Firewalls in the Cloud: How to Implement Trust Boundaries for Access Control

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the Senior Product Manager for Threat Detection here at Google Cloud, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.google.com. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show and argue with us and the rest of our Cloud Security Podcast listeners on LinkedIn as well. Today is a special episode because our content is also available as video on our LinkedIn and on our YouTube channel. Anton, this is a subject we've wanted to cover in depth seriously for a long, long time. And I think we succeeded at covering it in depth, even though it ends up being a somewhat unserious episode.

Yes, it ended up— if I go and start pontificating about a framework, how all the podcasts must be somewhat fun, somewhat educational, and somewhat motivational, I think we definitely hit the entertaining and motivational part quite a bit harder, but we also hit the informational part for sure.

The information is there for sure. Listeners, you just have to put up with a lot of nonsense from us on this episode, which I think is always fun. It's not every episode where we get to make bi jokes. It's not every episode where we all devolve into laughter. And frankly, this episode featured just the most outrageous metaphors. I thought, you know, cloud providers HOA was one metaphor that Charles provided us a couple of weeks ago, but Michelle really hit it out of the park on the metaphor game.

I think they were crisp, but at least one of them smelled a little.

It smelled quite a bit.

And with that, listeners, let's turn This is yet another live video recording of Cloud Security Podcast. And our guest today is a repeat guest, Michele Shibirka. And the topic today is a topic that we've tried joking about during many episodes, but we never truly covered it. We made throwaway remarks about, like, hahaha, firewalls in the cloud, or, no, no, no, you do need a firewall in the cloud under these circumstances. But we never kind of went All consistent and systematic, to use the word from my previous job, like systematic view of how to think about it. And that's why we invited Michelle, who has a very architectural mind. Is this fair to say? Architectural mind?

Architectural and skeptical mind, maybe skeptical too.

Okay, fine. I'm gonna avoid trying to be funny today.

Did you break Michelle with that comment or did her video freeze?

I think we may have broken Michelle. So interesting.

Oh, wow. An architectural mind means goodbye.

Oh, we completely— architectural mind caused the buffer overflow in Boomcaster. Interesting.

So that's too funny. Make sure you readmit her once she tries to log back in.

I am hoping for that.

Well, wait, wait, wait, wait, wait.

Now you have to tell jokes while we are waiting.

Let me get my hat out. So, listeners, I got sent this hat by a big Cloud Security Podcast fan because when he and I were on a call professionally, he asked me what my favorite cereal is from his company. And I answered this, and now all of a sudden I have a beautiful hat with which to enjoy my cereal every morning. So shout out to the anonymous hat sender. Thank you very much. And I'm delighted to welcome Michel back to the call. Maybe, Anton, you can ask our first question to get started now that we're done with the messing around portion of the call.

Let me do that. And I think that I'm a little hesitant to do this because I've asked this question about— similar question on Twitter in the same form, and people made fun of me incessantly. Yet I still think of it as a very appropriate mental tool, a 3:00 AM test. So Michelle, imagine somebody wakes you up at 3:00 AM and says, hey Michelle, do we need firewalls in the cloud? What's your first reaction?

Okay, first, I have been a firewall admin and people did wake me up at 3:00 in the morning. So here I'm getting—

Oh, so it's for you, it's very legitimate.

Okay. I'm going through PTSD all over again. So it depends. That's the standard architectural response that I will use through time immemorial. And I think it depends on a lot of things. First, are you migrating to the cloud? Is it a new migration? And let's level set here. When we talk about firewalls in the cloud, are you talking about the software-defined firewalls that you can get, or are you talking about the cloud-native firewalls that they call in various cloud providers? Because they do call them— now they call them firewalls, right? You have different Network firewalls, WAF sometimes, or, you know, it's a web application firewall, so it's called a firewall. So you still are using firewalling capabilities.

By the way, do you know what Google Cloud calls its firewall product?

Yes, we do. We do.

What do we call it? I would guess we call it the Google Cloud Firewall. Exactly.

Thank you.

Listeners, this is like the opposite of, do you know what they call a Quarter Pounder with cheese in France?

Did you just make a Pulp Fiction joke?

I did, which is probably like passé for some of our younger listeners.

No, I don't think so. I don't think, I don't think that, that's always cool.

That's one of my all-time favorite movies, by the way.

Actually the same. So that's, I'm a little embarrassed to admit that.

So firewalls in the cloud.

Yes.

Yeah. So, you know, basically my favorite definition of a firewall is a router that doesn't work. That's one that I've been using for a long time.

Okay.

And Essentially, that's what you're doing, whether you use a vendor's software firewall, you know, a virtualized firewall, or you're using the cloud-native one. In my opinion, if you're migrating, if you're newly migrating to the cloud, there are definitely cases for using the virtualized firewall, especially if you still have a large on-premise You know, if you're that— I'm gonna pull out a Gartner term. This will probably trigger Anton. Bimodal IT. Remember that? Yes, of course.

Actually, I loved it, by the way. This is one of the Gartner concepts that died before its time. It shouldn't have died, but it did die. And I want it revived as a zombie.

Could you tell me what that term means?

Okay. So, bimodal IT. Sorry for hijacking the conversation, Michels, because I'm so, like, triggered by this. So, a few years ago, maybe like 10 years, Gartner came up with a concept of bimodal IT. which is a company where, say, you're a mainframe admin. No, I'm a mainframe admin. You're the Kubernetes admin. We live sort of in separate realities, and you run fast, you do DevOps, you have SREs, but I do things the old-fashioned way. And we coexist, and everything's kind of fine in that sense that we exist in kind of overlapping semi-parallel world realities in the same company. And you may update code every 2 minutes and I update code every 2 years and everything just works. And the— okay, but that's actually how it stays for a long time. And the model was how to manage it well.

Oh, interesting.

I really did see a lot of companies like this.

Yeah, I see them all the time too. Yeah. I mean, that's the reality, right? Most, when they're not tech companies.

I thought bimodal IT was when you hire a bunch of queer people like me to run your infrastructure, but... Listeners, that's disappointing.

I'm fawning under my— what am I fawning under?

Okay.

All right, so back to firewalls in the cloud. I keep killing us this morning.

The point I'm trying to make by bringing up bimodal IT was not— the intention was not to let Anton go off on a tangent, but that's always fun, right?

It's always fun.

But the intention was to point out that most organizations will have— you can call them, you can use a, you know, a very derogatory term, you know, like legacy, But the reality is that you're in varying stages of maturity depending on your line of business in a large organization. And, you know, as you're trying to migrate to cloud or as you're trying to get more— become more cloud native, you're going to have— let's say you're using Check Point firewalls, right? And that's the way your security team manages that environment. To all of a sudden say, oh, by the way, we're going to use a bunch of firewalls in the cloud because that's really the best way to do it. So you need to either get along or get along.

Right.

Right out the door. Well, that's not really reasonable or very collaborative, and it's actually not going to work very well. You'll get a lot of blind spots in your security architecture. So I think that's a perfectly valid use case that when, you know, you're migrating into the cloud or you have that bimodal infrastructure or hybrid cloud, that may be a use case. For example, if you're in multiple cloud providers, It's if you want a consistent layer of firewalls that you are used to managing and that you can manage centrally, that may be a use case. That or you could get— what do they call it? A CSPM, right? The Cloud Security Posture Management tool or some— actually, there are ways to use different companies' security configurations for, you know, hybrid cloud. They have tools that can do this that not only look at the security of your infrastructure, but allow you to track how you're managing your construct of a security architecture, including firewalls centrally. Right? Does that make sense? We following?

Yes.

Okay. So that's a perfectly valid use case. I think that's my point. I don't want to beat up on people that make that choice. However, I think there are also reasons to not do that as well. There are pros and cons, right? Yeah.

Let's hear the cons.

Okay. Expense.

But wait, wait, before I go further, sorry for interrupting. But because we sort of still mix firewalls and appliance thing that got dragged in the cloud using a tow truck versus a cloud-native firewall encoded in CSP, and we kind of still conflate them, right? Like, I feel like pros and cons are separate for whether you are lift and shifting the firewall appliance versus calling an API to block network access. I'm sensing that we are still in the firewall versus firewalling confusion a little bit. When you say pros and cons, are they— what are the pros and cons for?

Well, they— those guys are catching up. Let's face it. A lot of cloud providers allow you now to manage using their firewall management capability, their central management console. You can manage a third-party firewall tool. So yeah, they're catching up, but the reality is that When it's not from the cloud provider, there's a level of complexity because now you have to worry about plugins. You have to worry about does it can I okay that's a different API call if they even have an API call that's a different one right and I've got to learn that somebody's got to code for that right there's also the complexity because now you have to worry about two things breaking well it's not just okay I have a problem with you know, the cloud provider interface and the SDK. Now I have to worry about what if, you know, if the infrastructure as code pipeline breaks and it breaks on that, oh, well, is it because the API with that software, that virtualized firewall from a third party didn't work, or my cloud provider call didn't work, right? So, there's the complexity.

I think you're making a really interesting case here for for cloud-native tooling?

Yes. I think ideally, unless you need, for example, some capability that, you know, a cloud provider doesn't have, you know, it's that KISS idea, keep it simple, stupid, right? So, you wanna try to make it easier for your development team because a lot of times they own the infrastructure as code pipeline. I mean, there's still a lot of fighting about that, don't get me wrong, right? You have, sometimes you have cloud engineering, you have security engineering, and they're all wrestling over, with the development team who's gonna own what part of the pipeline, but they don't collaborate. What happens is they just break out the sections, and now you broke your wonderful, like, you know, development pipeline that's supposed to, you know, work and instrument together very smoothly, and now it doesn't anymore, right? That's another story.

So, this is another case where we don't need more technology, we need a family therapist to get the teams working together.

Yeah, I think we are. That's exactly right. But we are also— we need a therapist not just for seesaws like we covered in previous episodes, but for recovering network engineers, I guess, right?

Yeah, I think every network engineering degree should come with, like, a 5-year redeemable coupon for about a year's worth of therapy.

Yeah, like, the first— I remember the first conversation I ever had with a network engineer, and I may have— I probably told this story about how arguing about, you know, the problem, why don't those development people— I go and I tell them to turn off access to SSH, and then every The next month it's back. And I said, well, you know why that is, right? No. Well, because it's in the infrastructure as code. And unless you do a pull request or you change the code yourself, or you talk to them, it's gonna keep coming back. So, you, congratulations, you're a programmer. Like, that's what I told him. Anyway, go ahead, Tim.

The voice you did there for the network person, you sounded just like my mom. She runs network operations for Citibank, and she says that about the application people all the time.

Oh my God, is this dangerous? Because I think Tim accidentally invented the concept of a mom joke as to like be a partner to a dad joke.

No, I think the real danger is that my mom probably is going to listen to this and call me up and be like, Tim, what are you saying?

Tim, I just want to— in defense of your mom, I was— I'm a recovering network engineer. That's how I got into firewalls. So I'm here to defend your mom.

Good, good, good, good. Somebody has to. So I want to talk about trust boundaries, which is what firewalls are all about, but in the context of cloud-native stuff. So the traditional things we solve with a firewall, trust boundaries, how do we think about that within, say, Kubernetes or within serverless or within our managed data systems? Because clearly you can't put a firewall between 2 BigQuery tables. There's no computer there to firewall. It's just APIs talking to each other. So how do we do that right?

Well, that's why you have native capabilities from cloud providers that understand ephemerality and immutability, right? They also understand, you know, you have service mesh, you have concepts of, you know, where you can orchestrate along with the way you orchestrate and deploy infrastructure in an immutable fashion, right? Unfortunately, that is not going to be a concept that you have with a virtualized version. I mean, they're trying. That may not be the case in another year, but right now it's still a little Easier. It's more friendly. Let's say developer-friendly. How's that? Cloud-friendly. That's a term I like to use because it makes more sense to people than cloud-native. That doesn't really make sense.

Cloud-native, correct. Yeah. I understand what you were trying to say, just cloud-focused, but I think cloud-friendly is—

Yeah. Does that give you enough detail? I mean, without going into the details of service mesh, service mesh, of course, but even without service mesh, you have Can we briefly detour into service mesh?

Because the thing still confuses me a little bit.

What is service mesh? Okay.

Thank you, Tim. I was about to say that, but I was too embarrassed to say, what is service mesh?

No, what's service mesh?

Are you gonna make me explain, try to explain service mesh now? I mean, service mesh is really—

Yes, yes, exactly.

Thank you.

On air, without any prep.

I didn't really prepare a good definition. Now I'm upset.

No using Google.

It's really—

But Bard, Bard, she can use Bard.

Oh, should we use Bard for that? That is a great idea.

I'm already on it.

Okay, now we're at a detour from a detour.

No, now we have to use Bard.

I just asked it. We'll see what it says.

Okay, what does it say?

It's working. It's spinning. Anthos Service Mesh is a service mesh.

Oh, are you doing that? You're doing that now?

Yeah, yeah, that provides a way to manage and secure traffic between microservices.

Okay, I would explain service mesh. Maybe we can compare definitions. Okay.

Okay.

I would explain service mesh as a cloud-native way to create access control methodologies, to apply access control to immutable and ephemeral infrastructure. That is what service mesh essentially does. It does that by hooking into the cloud-native infrastructure of Kubernetes, say. You don't necessarily have to use it with that, but it's certainly more aligned with that technology. And, you know, through a series of side— you can use sidecars, you can use eBPF now, but the essential nature of it is it understands Kubernetes, where that's the other problem with a, you know, a standard virtualized firewall, that they— it's not really made for that, you know, fast-moving, ephemeral infrastructure of Kubernetes. Are you buying it?

No, I think I think that's pretty good. I think Bard might have done you one better though, because Bard gives us three features: traffic management, which we covered; observability, which is very important; and security. And Bard managed to use the word zero trust in its answer about security.

What?

Oh no! Okay, if we were doing this later in the day, well, it's it's after it's afternoon here, so we should we'd have to take a shot for zero trust. We should have a drinking game.

But it's not it's it the human didn't do.

Every time you say zero trust, I should have to take a drink.

Oh, you should take a drink.

Yeah, for sure. Yeah, we can't let the robots get us drunk though. That's like step one on their uprising.

I think so too.

But I did say observability, FYI. I used the code word eBPF. Ah, that's fine.

I think there's no, no drinking involved here.

Yeah, it's too early for that.

Okay, so back to where we were.

Yeah, okay, back to where we were.

Okay.

This is kind of a trick question. But it's not a surprise question. It wasn't—

it wasn't a trick question if you say it's going to be a trick question.

Really? Okay, fine. I'll try it anyway. So, Michelle, can you imagine a modern cloud-native architecture that includes a firewall appliance or a traditional firewall?

Oh, okay. Yeah. So you're talking about old school. Okay. Kind of.

No, no. But in new school architecture with an old school firewall.

Appliance.

Appliance. Yes.

Yes. I could see. I don't. I don't think it's probably going to be low latency. I don't think it's going to be the most cost optimized, right? Because now you're using an abstraction tool in an environment where you really don't want to create more abstraction layers. Yes. But for example, I have seen financial operations that actually don't allow their cloud environment to egress out directly. It egresses back through their on-premise architecture. their network architecture. And there was a valid reason for that, right? It had to do with the introduction of HSMs, and they needed to use their physical HSMs at the time. This is a few years ago before they were at the right FIPS level, right? So I could see that. I mean, it's not the most efficient, but that's a realistic use case. There also might be reasons where you create an edge account architecture where maybe a network and security team manages the edge stuff and all of your developers only have access to accounts or organizations that are— or projects that are only internal, that only have internal IP space. So, you have— it's about Conway's Law a little bit, right? But you have certain teams managing the edge infrastructure that hold all the public IPs, And then you have developers only accessing this internal stuff. And that would be a perfectly reasonable use case, I think, for maybe somebody using a virtualized firewall.

But, but, but, but doesn't that sound a lot like hard, crunchy exterior, soft, chewy inside of the '90s architecture?

Oh, I used to call this, I used to call that the firewall sandwich. You know, the firewall sandwich, right? Yeah.

Right. With multiple layers of firewalls.

Sure. Yeah. Where you have like, you have the 2 layers, you have the one before you get the DMZ, and then you have the one at the edge.

But I think it's a different reference though. It's that you have no controls on the inside.

That's right.

I don't think it was the point about multiple, it wasn't the sandwichy aspect, but the fact that there's a chewy, gooey center, that there's no security in there.

It doesn't mean you necessarily have to have, you know, Tootsie Roll Pop security, right? That's what I also used to call it. You know, 'cause how many bites does it take to get to the inside of the network? the chewy inside of a network? Yeah, I don't think it has to be that way, but it also means that you are— I see that that kind of architecture where you would have a perimeter account managed by networking and by security, and then you would have developers managing the internal accounts that don't have public IP space. In that scenario, I would see that more about Conway's Law, right? You're designing an architecture that really reflects your organizational structure, and it's just, it's expeditious. It's not the best, but it's probably the path that you're gonna take as you are maturing in cloud. Because it's not just, you know, one and done, right? It's you're slowly maturing over time in the same way that your DevOps maturity, you know, builds over time, right? I don't know if that answers your question, but—

It sort of does, but let me—

Okay.

Sorry, let me interrupt our regular programming because we have actually a good question from the audience. from LinkedIn.

Really?

But I have to give a little bit of a preface to it because you should hold on to your chairs because it may blow some purist minds because this question is about a particular— okay, I'm going to make a snide remark— a particular type of a firewall called web application firewall.

Oh.

Oh, boy.

Which, of course, we all know is not a firewall at all, but it's a question about Okay, fine. Michelle is on more of a balance. Tim is more like, get out of the room kind of thing. But it's still a fun question. So, people who like— I'm going to rephrase the question a little bit. So, the question is, if there's a WAF, why should developers care about security? But I want to bring it a little bit more to the context of this. Some people actually advocate for hard shell, chewy interior.

Yeah.

Because for them, it's a benefit. They don't have to do anything security-wise for the inside. And how do you deal with that? Like, what do we tell them?

Defense in depth.

But they say, we don't want that. We say— well, you say defense in depth. They say extra complexity.

I agree. It's a conundrum. It's a conundrum.

Pillow fight. OK. No, no.

I mean, this gets back to what's the job of a CISO, right? Is the job of a CISO to make the organization maximally secure? Or is it to make the business succeed?

Well, wait a second. Wait a second.

I don't think—

and this is— This is probably why CISOs get so stressed out, right? I don't think it's just the CISO's job to do conflict management in the organization. I would assert that the responsibility of every single security professional is conflict management, right? And that's really what this is. Well, first of all, don't get me started, one, on WAF, which we all know that the WAF never gets tuned, right?

Different episode.

Never gets tuned. So, they're going to say, oh, we're using WAF. And I'm like, oh yeah, what's your rule set? Okay? Nobody ever tunes it, so it ends up being junk.

Of limited value. You wanted to say of limited value.

Yeah, because it can be good.

You didn't mean junk.

You meant— But I'm not saying that the WAF can't be good. It can be good. But the reality is organizationally, they look at the rules a little bit and everybody finger points and goes, well, why should I have to configure it? The network people should configure it. They own the firewalls. Well, no, it's a web application firewall. We don't understand how your web application works. You should configure it. And then it's just a finger-pointing game. Nobody wants to take responsibility. That's why it ends up.

So it is a concept of a waff pillow fight. It's a waff pillow fight. Okay, so the waff comes. Yeah, it is a waff pillow fight.

Pillow fights being more fun than that, but okay. You know, maybe it's a waff pillow fight with bricks in the pillowcase.

Oh God!

In the pillowcases. Ah! Get your metaphor out of the room.

Okay, but. Yeah. Where were we? I think we just went off on, like, went way off topic.

I think it was fun, but yeah, let's go to the next question.

So I want to ask kind of the inverse of the last question. Can you imagine a modern cloud-native security architecture that excludes firewalls entirely? Imagine a cloud environment where every network is set to allow all.

Oh, not my— the university where I worked, but a competing university in The area where I live, and you guys can look this up, actually was notorious. They had a requirement to implement firewalls and it was just an allow-all rule. But they had firewalls. They had firewalls in place. So yes, I have seen designs that use it. Again, for example, if you have a dedicated perimeter account, which I have seen, and that in that scenario, where you have— it's about control and governance, and especially in a regulated industry, or say you're the federal government or something like that, I can definitely see that. Yes, I think we agree it might not be optimal depending on how you have it configured and designed, but I can definitely see that that would happen. I think as an architect, especially a security architect, I've learned to be pragmatic. You know, which hill are you gonna die on? Right?

Probably not who is tuning in. Please don't.

The analogy that I like to use, that my job as security architect is choosing between different piles of poo, right? Do you choose elephant poo, or do you choose the donkey poo, or do you choose the dog poo? They all smell, but you're worried about choosing the smallest, least smelly pile of poo, right?

Yeah, it's a— metaphors today are really on the ramp-up exponential curve. So this is like a 10x. 10x metaphor at this point or not?

I don't even know what to say.

But Tim, it doesn't smell right. I don't know why.

Tim is disturbed by my poo analogy.

Yeah, no, this is— please continue. Let's move right along.

Yeah, the expression on your face is like, I've never seen anybody so disturbed by that analogy because I've used that one for a long time.

Okay. But so I think the picture is somewhat clear. So let me try to go and move us along again. to a question that can potentially take another 30 minutes to answer. So, how about we be brief? So, when people think firewall, of course, some people say firewall and IDS, and they go full-on '90s on security controls. But think about it. What about firewall? What about network IDS? What about IPS? How do these other things play in the cloud in your mind? Should people use these other traditional components? And if yes, how? We will have a very fun episode very soon with a person who pretty much invented an IDS, and, uh, it would be really fun. So I'm going to leave it as a cryptic comment. So, well, sort of invented— he invented his own IDS, not all IDSs.

I tried to invent my own IDS too, really, using semantic web technologies. This was like 10, 11, 12 years ago with a research partner. Yeah, anyway, I have a paper on that. You can go read it.

So what do they play?

Yeah, I think that the capability is just called different things. It's like a NIDS is just, I'll say, network IPS. An IPS capability is now you achieve some of that with zero trust, with reCAPTCHA, things like that. reCAPTCHA Enterprise, the newer version of that. I think there are different ways that you're doing it. Essentially what you're doing with an IPS is you're taking threat intelligence and making choices about what traffic you're going to allow or disallow, right? You don't necessarily do that with an IDS or an IPS in the cloud anymore. It's just, I think that for me is why I'm so adamant about focusing on capabilities and features versus products, right? You can get easily hooked. For example, you know, we used to always build network visibility layers, right? What does that look like in the cloud? It does not look like the way you used to do it on-prem with taps and, you know, Gigamons and things like that, it looks very different. So, I think that's what is really important, to become educated and then focus on what the capability is. Is that too much of an architect answer? Is that fair, or...? This seems like an extension of what we were talking about with, you know, architecture, you know, when you migrate to the cloud, and the problem being the way you treat the architecture, right? And doing a lift and shift. And there are times where you're going to do that, where I have seen, for example, that, you know, load balancers, I've seen that use case where somebody just didn't wanna rewrite all their F5 rules, right?

Who would?

Who would? That's right.

Yes, exactly. And to expedite it, they used the virtualized version, right? That I didn't like it, but cloud migrations are trade-offs, and a lot of the trade-offs come in security, unfortunately. So, the best thing you can do as a security SME or security architect is be prepared to negotiate. Be prepared that you're going to have to make some trade-offs. It doesn't mean it has to stay that way forever, though.

All right. Well, Michelle, as much as it always pains me to say this, it pains me extra today. Time for our traditional closing questions.

Okay.

One, do you have recommended reading? And 2, do you have a tip to improve people's thinking perhaps about firewalls in the cloud?

I think the list we have, the Ross Anderson Security Engineering book, and I'll make a recommendation. When I first learned coding, which I'm not gonna tell you what year it was, but when I first learned to code, I remember the guy said to me, don't memorize libraries or try to memorize algorithms, right? try to think. This is an exercise in critical thinking, right? You need to focus on the problem you're trying to solve. And I think that's important when you're asking that question about do firewalls belong in the cloud, like virtualized firewalls that are more akin to the physical counterparts. I think you need to consider what your journey is, where you are in that journey, and understanding that it is a journey and it's not a here, we're done now, and we're never gonna look at it again. And I think the classic books, such as Ross Anderson's security engineering book, you know, a lot of the books on, you know, CISSP, I really recommend the way the Cloud Security Alliance approaches it. Also, I think the Cloud Native Computing Foundation. I think the Cloud Native Computing Foundation actually has some really good recommendations on how you build security in the cloud, right? Hmm. And they also have the interactive landscape with all the different tools that are in different states, some commercial, some, you know, open source and incubator or sandbox. And they can give you ideas for how they approach it. And, you know, there's always with KubeCon, Cloud Native Computing Foundation also has a parallel conference with that. So I think it's time for us to sort of not fight about it and say yes or no, but to say it depends, right? And a yes, and okay, we're here to figure it out.

Don't be afraid of it depends, I guess, is the—

Yeah, I think so, because this is cloud, and cloud is more of an open-world logic problem and less of a closed-world one. It's a semantic web thing.

That makes a ton of sense. I met Ross a couple of years ago at a Weiss conference. And he is just as curmudgeonly in person as he is in his writing. It's amazing. You read his writing, you're like, there's no way this guy's actually like this. And then you meet him and you're like, wow, that guy really writes in his own voice. It's actually impressive.

I can't believe you met him. I, that's the coolest thing ever.

Yeah, no, he was, he was great. He was really cool. Great, great curmudgeon. With that, listeners, thank you so much for joining us today. Michelle, thank you for joining us. This was a ton of fun.

It's always a pleasure.

And now we are at time. Thank you very much for listening, and of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter, @Anton_Chuvakinen, Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security.