What do you need to know about when moving from on-prem to Google Cloud? In this episode Ashish Rajan is joined by Jorge Liauw-A-Joe from Xebia, recorded live at KubeCon Paris. Jorge, a Google Cloud Practice Lead, shares his transition from on-prem to cloud environments and highlights essential security aspects within Google Cloud, including IAM, network security, and the use of Terraform for scaling security measures effectively
00:00 Introduction
01:14 A bit about Jorge
01:37 Transitioning from on prem to Cloud
02:57 Google Cloud Fundamentals to start with
04:04 Auditing in Google Cloud
05:44 Network Security in Google Cloud
08:17 Firewalls in Google Cloud
09:22 Compute in Google Cloud
09:56 Security for Google Cloud Compute
10:43 Service Account in Google Cloud
11:32 Google Cloud at Scale
12:54 Automation at Scale for Google Cloud
15:59 Using Terraform for Centralisation
16:32 Common Google Cloud Security Services
18:39 Where do people use Third Party tools for Security?
20:21 Data Security in Google Cloud
21:23 Where you can connect with Jorge
Ashish Rajan: [00:00:00] Worthwhile calling out, what is a service account? I know. You and I kept it out. But the rest of the internet is like did he just say service account? Are you an on premise person trying to move into Google cloud? Or you probably have no idea what Google cloud is all about, especially from a security perspective.
Fortunately at KubeCon Paris, I spoke to Jorge from Xebia and we spoke about some of the fundamentals. Like we spoke about what's it like to have network identity, compute security, IAM security in. a Google Cloud environment. What are some of the elements you need to be aware of? What are some of the organizations doing in terms of scale?
And how can you use Terraform and similar languages to scale out security and what some of the challenges in that space are? It's a really interesting conversation at KubeCon Paris. I hope you enjoy this. And if you know someone who's trying to move into the Google Cloud space, this is a great introductory video conversation that we had with Jorge.
And I hope you get to share this with your friends as well, so they can get to do better Google Cloud security. If you're here for a second, third time, you know the drill. Definitely give a subscribe and follow. If you're watching this on YouTube and LinkedIn, give us a review or rating as well. If you are listening to this on iTunes and [00:01:00] Spotify, really appreciate the support you've given us all these years and continue to do that so as well.
I hope you enjoyed this episode of Google Cloud Security Fundamentals with Jorge from Xebia and I will see you in the next episode. Peace.
Welcome to Cloud Security Podcast.
We have Jorge here from Xebia. Could you tell us a bit about yourself? What was your journey in the whole cloud space?
Jorge Liauw-A-Joe: Yeah, of course. Yeah. Thanks. Thanks for having me. So my name is Jorge Liauw-A-Joe. I work at Xebia as a Google Cloud practice lead make sure everything's secure, but also as a Google Cloud architect really helping customers designing and building secure solutions on Google Cloud.
And actually I really love the cloud, specifically Google Cloud, but I started on premise.
Ashish Rajan: Oh, actually, maybe that's a good point. What was your journey to go from on premise to, because I'm pretty sure we have a lot of people in the audience who are probably still working on premise and I think there's a large Community in the on the internet, which has not really migrated onto the cloud yet.
So I imagine if you can answer questions for them as well there, what's the transition like from on premise to Google Cloud?
Jorge Liauw-A-Joe: Yeah actually, so I started all with VMware, having co [00:02:00] locations, really the hardware, that's really the painful part looking now back from the cloud perspective. But then I was really looking for solutions, like how can we scale it like really rapidly, right?
You can call some hardware provider Hey, I need some more resources, give it to me. You get the the proposal. And then two weeks later, you maybe have the hardware, you need to provision it. And then maybe downline, you have it in four weeks you're able to use that new power. But yeah, looking at the cloud, we can actually start, after our podcast, you can start ramping up some workloads would it be virtual machines or containers.
And that's something that we love the skill, but also the speed. In the way you can set it up.
Ashish Rajan: And do you find the transitioning from on-premise to the Google Cloud world, was there knowledge that you had on premise that was easier to move into the Google Cloud space?
Jorge Liauw-A-Joe: I think the things on networking and also how the hypervisor layer, that kind of stuff, but also translating like freelance, how does it work in the cloud world?
So because you already work and know the concept, you just need to translate, like, how does it work for this cloud specific.
Ashish Rajan: Worthwhile also covering things like from [00:03:00] a basic layout perspective for people probably watching this because we are talking about Google Cloud security fundamentals. What are some of the, high level components that people need to understand about a Google Cloud environment? That you think people should be aware of? When they're looking at a Google cloud environment,
Jorge Liauw-A-Joe: I think it all starts first with the structure, right?
So how you want to structure as your Google cloud, you have the organization, the folders, think about non prod production. And of course your projects where your resource live. I think that's really good to think about that. But besides you also have the users, right? The whole IAM part, how are you going to connect it?
Where are you going to sync the users from? Because what I see a lot when provisioning new users to the cloud. Yeah. You want to make sure they're in sync. If you talk, for example, about the joiner, mover, leaver when somebody comes into the company, the accounts are provisioned, they have access, can do all the beautiful stuff, but it's also really important to revoke the access when they leave.
Yeah. So things really start with IAM, and the structure is really important. And I think what's really a good guide also to use is a Google Cloud blueprint. It's all foundation and talk about the hierarchy of the, how to structure it, but also how to work with [00:04:00] the workloads firewall default compute accounts, that kind of stuff.
That's, I think is really helpful.
Ashish Rajan: And I'm going to map a few things that people normally consider. For example, from an auditing perspective, like a lot of people care about the fact that, Hey, in my on premise world, I can look at any audit log, the server, whatever. I put that into a central log file, like log aggregate or whatever.
What is that in Google Cloud world?
Jorge Liauw-A-Joe: Yeah, I think what's really nice because what you mentioned, for logging you need to set things up, right? Yeah. In Google Cloud it's there by default. Oh, yeah, you What's the service called again so people would know? You have the Log Explorer.
Yeah. And of course you have the audit logs, the data access logs, that kind of stuff. Yeah. But the cool thing is you don't need to set anything up in order to make that possible.
Ashish Rajan: It's already enabled for everyone?
Jorge Liauw-A-Joe: By default the logging is there. Yeah. But in the end, if you look at logging on the larger scale, you can actually send the logs to dedicated projects where you have the logs.
Think about if, for example, if you remove the project, then you also remove the logs about these projects. So that's why you want to keep it in a central Right.
Ashish Rajan: And we mentioned identity, we mentioned logging already. In terms of security fundamentals for Google [00:05:00] cloud, what are some of the things that come to mind in terms of whether it's network security or whether maybe let's start with network security.
We can peel off layers. Where do you feel? So we spoke about the structure. You have to help lay out such a for organization folders. Projects. Now we're, we've set that up. We have IAM. We've done federation. Hopefully that'll be a good one to put that in there. Do I need federation? But if I'm just someone who's trying to be like a, Yeah. I want to experiment with Google cloud. Yeah. Do I need to have Federation or can I just have my own Gmail account?
Jorge Liauw-A-Joe: Yeah. I think if you want to start your, for example, you Google cloud free tier, then you can just use your Google account to explore it and take it from there.
But if you want to connect it on enterprise level with a Google workspace or maybe your Azure domain, then I think that's will be the way to go.
Ashish Rajan: And we say after a certain level of maturity, cause I'm trying to give a perspective where people get an idea from, Hey, You can start at a small scale where you have an organization, folders, projects with one or two compute services and you're not doing much.
You're like, Oh, I'm just going to experiment because I'm [00:06:00] not sure if Google Cloud is the right one for me. You do that for six months. You have done auditing as well because you have audit logs, log explorer, all of that. And you're trying to move across to Hey, now, okay, now I can do some more serious projects in terms of the first one for network security.
Kind of coming back to that. What are some of the network security components people think about when they are trying to build in Google Cloud? I
Jorge Liauw-A-Joe: think by default, when you create the networks, the VPC networks, then you want to make sure you use the custom ones, because with the defaults, when you get certain firewalls that you don't want to have there.
So you want to start from there. So you can define what subnets and from there you can create the, of course, you want to do with Terraform, infrastructure as code. Okay. To make sure, okay, what firewall rules should be there using the firewall tags and not all instances here VPC for example. So I think those are really important, but I think even more important is where to start.
Know what you want to deploy, because you mentioned like, when do you maybe structure differently your Google Cloud? I think it also depends that you, are where what you want to do today, but maybe in the future. So I have an idea on that. To make sure you don't need to reorganize everything along the way.
I can imagine what you say if you're going to [00:07:00] experiment and then start small. Yeah. But I think specifically in startup can go really rapidly crazy. Yeah. And then people doing things manually, maybe by code, G Cloud.
Ashish Rajan: As people are looking at network security from a VPC perspective, something which is different about other clouds.
And I wonder if we can share some light on that as well. A lot of people go, Oh, So if I'm in a network, I've got two compute instances, my two compute engines in one network. Yeah. Do they automatically talk to each other or do I have to have a firewall rules to allow them to talk to each other?
By default, they can talk to each other. So I don't have to have that because they're in the same network. Is there the whole region zone concept? How does that work in Google Cloud?
Jorge Liauw-A-Joe: That's a good one because it's on top of my head. But I think you can even go from one network to the other one even across regions.
Ashish Rajan: Yeah. Across regions as well.
Jorge Liauw-A-Joe: Yeah. Okay. That's true, right? Because I think that makes Google unique in that sense compared to the other one. Yeah, because I was gonna say,
Ashish Rajan: because other people have that region. If I have a network in one region, I can't automatically talk to the other side with some kind of peering or extending going through the Internet or whatever.
But in Google Cloud, the networks in the same region can communicate through [00:08:00] firewall rules, I imagine?
Jorge Liauw-A-Joe: They can communicate through each other. Oh, wow. Okay. And one of the other things when you come back to networks one lovely thing, I don't know how it works in the other cloud, like the blue or the yellow one, but the shared VPCs where you create one network and you can have VPC peerings to other networks and then you can start to manage all the firewall rules, for example, and the subnets.
Ashish Rajan: It's worthwhile calling out, because a lot of conversation also comes from a cloud native versus, hey, I already have a firewall. Insert company name here. I'm not going to name a company.
Jorge Liauw-A-Joe: I know a few, but yeah.
Ashish Rajan: So I already have a firewall in my on premise. Do I need to migrate that firewall to the Google Cloud itself?
Or are there services in Google Cloud that I can use to do that kind of scaled out firewall thing as well?
Jorge Liauw-A-Joe: Yeah, there are a lot of things. Of course, you have the basic firewall just to protect compute instance You have the firewall plus tier. That's more yeah, it's next gen firewall actually from Palo Alto as a managed service So you can do the hefty lifting for you, but there you have intrusion detection intrusion protection Yeah, and that's pretty cool because you can fit it in pretty nice and easily within your VPC network.
[00:09:00] Yeah so that's really a cool thing things like a proxy server to make sure you can filter the egress proxy, you can set up squid and all that kind of stuff, manage the insert group, but you can also again have the secure web proxy for you, and you just define the whitelist also in Terraform, and you can just provision it, so you can stay in control and you know what's going on in your network and what can go outside and of course it comes inside with the firewalls.
Ashish Rajan: And maybe adding that to the compute side then, obviously you can see where I'm going with this, I've got network, I'm going to talk about compute next. But obviously we want to talk about scale as well. In a compute security sense, what are some of the considerations people should put in? And, because I don't even know what people would understand compute.
They think it's servers, so what's an example of service in Google Cloud, which is the same as server on premise?
Jorge Liauw-A-Joe: You mean Compute Engine? Yeah, Compute Engine.
Ashish Rajan: Yeah, Compute Engine, like the virtual machine. Yeah, virtual machine functions, there's App Engine, there's a lot.
Jorge Liauw-A-Joe: Yeah, I would say App Engine is back from the days when this started, but you have Cloud Run, GKE of course, and there are Kubernetes, you have the managed Kubernetes, the Autopilot.
Yeah. So that's pretty cool.
Ashish Rajan: Yeah. What's security for those that look like then? Obviously I [00:10:00] understand that we have a hypothetical application we're talking about this application nuances outside of the whole application nuances from an infrastructure perspective.
What are some of the considerations people could put in?
Jorge Liauw-A-Joe: Yeah, I think, for example, what to focus on serverless, but Compute Engine, for example, is like the default service account. So actually the permission that the compute instance itself has to communicate within Google Cloud. And normally that's pretty broad, the permission that are there.
So they're, I think they're an editor. And yeah, actually you need to limit it, to looking at the, Least privilege principle. Yeah. Make sure it's your only limit or give the permissions that are needed for certain roles that also applies for service account, not only for users. So I think that's really important one to take a look at that.
And you see it by most of the service that the default service account for compute is there. If you just create it in a normal way.
Ashish Rajan: Actually worthwhile calling out what is a service account. , You and I kind of blurbed it out, but rest of the internet is like, did he just say service account?, because I know there's a service account concept on premise as well where a system account, they're like, oh, it's my system manager account. Yeah. But. I'll let you explain what service account is.
Jorge Liauw-A-Joe: For example, in the on premise world, when I create a service account, that's [00:11:00] actually when the server itself does authentication or some function.
But I would say similar is also in Google Cloud itself, right? When the compute engine runs, it communicates with the metadata servers or something else in Google Cloud or other APIs. That's where you have the compute engine. You need one at least to make it work. And you need to limit also the permissions and the API scope.
So can it, for example, write to cloud storage bucket or only read it? Within your project. It's really easy as well, but you need to make sure you give it the right attention and the right permissions.
Ashish Rajan: I love how we went into identity. We did network compute identity. Let's talk about scaling it as well, where obviously you've worked in this space for some time.
What's an example just to give people a scale of how big environments can be and where does it scale? Is it more projects? Is it more folders? What does that look like? Multiple organization? Yeah. Yeah. Are there some examples you can share for what Google environments could be at scale because a lot of people maybe, and I'm not saying it's wrong, but on premise, the scale is looked very differently.
It's like I [00:12:00] work in a data center. The next data center, maybe I don't know. We're in Paris right now. The next data center, maybe in Amsterdam or whatever, but that there is a separate person for that. They look after all of that. I'm not looking after all of that, whereas I feel in the cloud world that's been generalized quite a bit.
I'm the one responsible for the Paris data center, the Amsterdam data center London one, because I'm like, suddenly. Because it's all software. I'll be curious to hear some examples on what do you see at scale people do with Google Cloud?
Jorge Liauw-A-Joe: What you mostly of course when they start off with your hierarchy when you have the organization, the prod, the non prod Yeah, and there you mostly for different departments that they have the old folders with the projects there But looking at scale with customers, they have more than 10, 000 VMs, for example Yeah, more like steady workload, but also with ephemeral workloads that they for example destroy them after a few hours But also scale up from 1 to 5, 000.
Yeah. And normally it would be a sweat, right? For the system admin. Yeah. But you just put it in Terraform and you're able to do this.
Ashish Rajan: Yeah, and maybe, because you mentioned Terraform as well. Because I think a lot of people talk about automation. Yeah. What does that look like [00:13:00] at scale? Now we've set the foundation for, okay, we've known networking, compute, identity, as well.
How much of this can be automated and how would you go about doing this?
Jorge Liauw-A-Joe: You can automate, of course, a lot, but first things you need to start with bootstrapping the whole project where you can from there have a template and start all the other projects. But what I really love, like one of the most beautiful setup that I've seen at customers while we worked on from Xebia is where, for example, if you go to the GUI, you only have read access.
You're like, Hey, What to do man as a DevOps engineer you want to do something and you want to do the nice stuff But then that's actually the only things that you can do if you need to provision or edit some resources or other stuff They need to go through Terraform. They need to create a merge request and edit the code and then push it back and then, for example, if you have slack or some other communication, just put it there, post Hey, this is my merge request.
Can you check it, validate it so other guys can also look at it? Okay, this is valid. This is secure. And then you push it through and then it will be a provision through the pipeline. That's actually I think the most beautiful one. Yeah. But maybe you think, what if you have [00:14:00] incidents, right? Do we go then into the Terraform and try to do this stuff?
I think that will be a bit harder. But then we have the break glass procedures. Now in Google you have the PAM the Privileged Access Manager, it's in preview currently. Okay. Where you can request certain access rights for a certain amount of time, and it will be revoked.
Ashish Rajan: Just to almost go down the Terraform path a bit more, with the whole idea of scaling, can we scale account creation?
Can we scale cause there's, obviously there's limits in other clouds for how much you can scale automatically, for example, the steps that have to be done manually, there is no automation for that. Is that right? So just to give an example of people, they can create Google accounts, they can create folders, they can create orgs, they can create compute instances so to the, all this, the limit is like where you stop thinking, is the limit.
Jorge Liauw-A-Joe: Yeah, and always what I try to look also in the Terraform registry, like what services being supported natively in the provider. Yeah. Because what you mostly with new services being released by Google, not always there's a Terraform provider. I know people might create it or add some good [00:15:00] stuff like that.
Ashish Rajan: So you can add some as well. That's a good thing. You can, so if you wanted one. Yeah. And for some reason, Google Cloud is not doing it. You can actually add your own provider as well.
Jorge Liauw-A-Joe: Yeah, but you also, for example, the magic module. For me, like really looking Hey, what's being supported?
And then from there, take it along. And something else for me, there are ways that I need to go the path of doing it more manually through the GUI or using G Cloud commands because the service is new. It's not being supported already, but it's just a way to do POCs. But in the end, you want to make sure it's ready for production.
And then it is there and you need to have it in Terraform code, I would say.
Ashish Rajan: Interesting. Do you find that like some of the people we were talking to, they have massive secret, centralization project, for lack of a better word. They're making a cloud platform.
Hey, we're going to use a HashiCorp vault, and that could be a central secret management vault for all of it. They might say, Terraform is our standard language for infrastructure platform building. Is that something you see quite often in Google Cloud as well? Where after a point, instead of asking a business unit to create an account themselves, You're building a platform team that uses Terraform to create an entire fleet of accounts for that business unit or something.
Jorge Liauw-A-Joe: Yeah, or you also [00:16:00] some see that the teams are able to create it themselves for IAM or the project in order to bootstrap it. But then you see that, the merge request, for example, they need to throw it into the platform team and they're able to approve it. But then from there on the pipeline, we'll do it for them in order to scale it.
Ashish Rajan: Okay. Yeah, you can still use Terraform for most of it as well.
Jorge Liauw-A-Joe: Yeah. Actually I only use Terraform, nothing else. I think I know there are other products, right? Maybe like wrappers around Terraform, but I think, it's good to stay with the original product. Yeah. Fair. That's for me. And I also know a lot of guys there.
Do a lot of great work. Yeah, but I know there's more in the market.
Ashish Rajan: Of course, the next question I have is and in terms of people who are building on Google Cloud, a lot of the other cloud providers. Yeah, they themselves have a bit of security gaps around terms of hey, not everything is solved cloud natively.
We spoke about the fact that there is already firewall capability. Other security process. But what are some of the common security products that you see people use from Google Cloud? And where do you see gaps that people need to fill with a third party that , we've always done that in on premise.
I just want to make sure people don't understand that. Hey, it's not that everything is solved by cloud. [00:17:00] So worthwhile starting off with what are some of the common security services you hear about and or people use and what are some of the gaps that are there that need to be filled up?
Jorge Liauw-A-Joe: Let's first start with the common security services that you see in Google Cloud that I see customers use a lot. First of all, I think security command center premium this one gives you a single pane of glass that you can see about misconfiguration, compliancy, vulnerabilities in your environment.
And also how you stack up to benchmark like CIS, from the hardening perspective. So that also gives you insight and okay, where do I need to take action to make sure that the workload stays secure? I think that's one of the great one Cloud Armor. Yeah, that's actually the web application firewall. will protect you against DDoS attacks and of course other attacks from the network. Cloud IDS maybe not a lot of people use it, but I really love it because you can actually do packet mirroring. Back in the days you need to mirror a port on your switch on the on premise. They can send it to the instance they're managed by Google and you can see is there malicious activity.
But there's actually more is there malicious activity between pods or VMs. And you can say, okay, what's happening there? Do you need to do something? So that was really [00:18:00] cool. We have the next gen firewall plus tier and with the IDS, but also intrusion protection and since it's in line in the traffic that was really great one because that's hard to scale.
For example, if it wouldn't scale your own solution, they will, you will lose network traffic coming from the outside or inside. So yeah, I think those are pretty cool. Yeah, and one of my love is not really network security is organizational policy constraints. Okay. We can set some constraints like these are the guidelines like where to deploy it.
How can you handle a service account? Are you able to deploy in Paris or just in in Groningen? Also every policy, there are policies for that. Yeah. That applies to a new resource that you deploy. Yeah. And then you can stop them if they're not compliant. Okay. That's pretty cool. Yeah.
Ashish Rajan: Yeah. Yeah. And what are some of the gaps that exists where you find that people normally end up going on the third party path.
Jorge Liauw-A-Joe: Ah, good one. I know the question would go. No, like for example in the pipeline. Yeah. We use different solution from Snyk Fugue previously. You also have Aquasec, that kind of stuff, in the pipeline.
For example, that you want to scan the Terraform plan. Yeah. Are there misconfiguration [00:19:00] violations? Mostly see that they have like basic rules, but you can create custom rules depending on the business that you run. But you can scan it. You can inform in the merge request the end user, the developer Hey, are you on track?
And otherwise you can also block it. So that's pretty cool. But that's where we see that we don't use Google products, but then a third party. So I think that's really important one. And the other one is, for example, for the old school antivirus or the endpoint detection response. I thought it's emphemeral.
We don't need antivirus. Not even there anymore. As you were talking about, it just shut down right there. I'm like, no idea people still ask for antivirus, I imagine.
Yeah, and they, because Google doesn't have it in their portfolio, they have the cool things, right?
There's Managed Security Commands, but also the SIEM solution, Chronicle, but they don't have the antivirus. For me, it would be maybe that's a good decision to maybe add somewhere down the line. But now we see customers that they use third party for that.
Ashish Rajan: Do you see people use Chronicle?
Jorge Liauw-A-Joe: I see more people using it and I really love it because of course it's the SIEM side where we have all the insides and the correlation with security threats and making sure that we can see where, for example, indicators of [00:20:00] compromise within the systems that they have, not only cloud, but also on premise.
So that's pretty cool. But there's also the the source site where you can actually automate it from simply creating tickets in Jira. You don't want to do it manually. But also isolating endpoints that are, for example, infected, and that's pretty cool because there you can, really automate more and let the cloud work for you and really make sure you can scale actually interesting.
Ashish Rajan: And is there anything for data leakage by any chance
Jorge Liauw-A-Joe: there's a data loss prevention? Yeah, there's a DLP and you now also have some new info types. That's actually like what kind of category data I think about GDPR or personal identifiable information, PII data, but also now secrets and that kind of stuff.
Ashish Rajan: Oh, so it can help with that.
Yeah, exactly. So is that chronicle or is it another product?
Jorge Liauw-A-Joe: No, the DLP is a part of Google Cloud itself.
Ashish Rajan: Okay. Directly. Maybe premium support and get that, yeah. Yeah.
Jorge Liauw-A-Joe: You always get premium support. Yeah.
Ashish Rajan: Premium support. As long as you pay. Yeah. As long as you pay.
It's always included, right? Thankfully, Terraform is free for people who use it. It keeps scaling. Yeah. . Yeah. That's for free. So I think at least with worthwhile for people who are scaling out. [00:21:00] Are you like a Terraform cloud user or Terraform?
Jorge Liauw-A-Joe: Actually I use the Terraform cloud.
Ashish Rajan: Yeah. I definitely have been leaning more in that direction. I think I did a whole video on We had an AWS account and unfortunately we had the Terraform keys left on the internet. So you should have just gone to the Terraform Cloud and instead of doing Terraform on premise. But hey, that's a story for another time.
Jorge Liauw-A-Joe: Key management, watch where you store your keys.
Ashish Rajan: That's one thing. Yeah, that's pretty much it. But thanks so much for coming. Where can people connect with you, find you on the internet?
Jorge Liauw-A-Joe: Oh, you can connect me on LinkedIn. Jorge Liauw-A-Joe, maybe you can put it in the comments. I would put that in, yeah. But yeah, let's connect up.
And if you have any cool challenge or you want to have some thoughts, ideas on security, let me know.
Ashish Rajan: How to scale using HashiCorp
Jorge Liauw-A-Joe: Yeah, HashiCorp, scale your security on Google Cloud. And you know where to find me.
Ashish Rajan: Yes. Dude. Thanks so much for coming. Thank you, man. so much.
Jorge Liauw-A-Joe: Thanks.
Ashish Rajan: Thanks everyone. We'll see you in the next video.
Thank you for listening or watching this episode of Cloud Security Podcast. We have been running for the past five years, so I'm sure we haven't covered everything cloud security yet. And if there's a particular cloud security topic that we can cover for you in an interview format on Cloud Security Podcast, or make a training [00:22:00] video on tutorials on Cloud Security Bootcamp, definitely reach out to us on info at cloudsecuritypodcast. tv. By the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, you might be interested in our sister AI Cybersecurity, which I run with former CSO of Robinhood, Caleb Sima, where we talk about everything AI and cybersecurity. How can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring next as an evolution of ChatGPT, and everything else continues.
If you have any other suggestions, definitely drop them on info at cloudsecuritypodcast. tv. I'll drop that in the description and the show notes as well so you can reach out to us easily. Otherwise, I will see you in the next episode. Peace.