Ashish Rajan: For people who may not know who Karthik is, what was your pathway to your current position?


Karthik Prabhakar: Yeah. By the way, I heard a couple of the podcasts from the Kubernetes security month, amazing content, you know, for folks that haven’t done that, please go back and listen to it. So my background is, you know, the, I just have this sort of pension, the last many years of gravitating towards new technologies as the emerging


in the last few years, I was actually privileged. This has happened while I was at red hat. And then I joined tiger, which is the team behind Calico in the early days of Kubernetes. And it was sort of very fortunate in, I taught, I felt very privileged to have the opportunity to help influence the adoption and not even how.


Kubernetes networking and network security gets adopted in the sort of mainstream organizations as they, as the growth of Kubernetes has happened. And likewise, along the way, you know, worked with the Istio and other service meshes in the early days, especially this year. And you know, more recently I was at a company called Tetra rate.


And along the way, you know, working with everything from the big, [00:01:00] big, full cloud providers, including helping a couple of them with sort of build out their hosted Kubernetes offerings from a networking and network security perspective and a number of leading organizations, and what I’ve realized was as much, and as interesting as the stack is to some of us that know the innards of it.


Yes. A lot of the security organizations in most organizations and most enterprises were sort of struggling to reconcile the complexity with all of them. Technologies the products and sort of all of the buzzword bingo that goes on. So recently I decided to take a step back and started focusing on, you know, doing two things.


One is starting to play more of an advisory role to early stage startups like astronauts as a company, and working from a product advisory role perspective recently, but also trying to help shape the products in a manner that they can be more consumed or consumable by mainstream organizations. And on the flip side, also working with some of [00:02:00] these mainstream organization, mainstream security teams application teams in helping them adopt the technology in a manner in which they can sort of reconcilement understand what’s going on, try and minimize the extraneous complexity, which tends to exist in a lot of products.


And so that’s what I’ve been doing in the more recent past and, you know Especially with these days with the amount of scrutiny on cybersecurity and the amount of investment going on. It’s, it’s an interesting challenge to keep those sort of forces you know in, in, in harmony.


Ashish Rajan: For people who may not have captured the K8 security month, Istio is an interesting one as well, because that’s kind of where I feel cloud native networking, starts getting a bit complex for some people.


It’s quite comprehensive. You’re able to kind of see the inside and say, divide an application, aware network kind of a thing. So I could not think of a better person to come bring in for the show.


So maybe a great place to start would be from a, network security in a cloud context. What does that mean for you?


Karthik Prabhakar: That’s a very broad question, because it’s like, you know, 12 blind [00:03:00] men and an elephant. Everyone has a different perspective. Let’s sort of step back from this a little bit.


. So if we first look at what does a cloud context mean for people and what is like, you know, like what does it mean to be on a cloud and you didn’t qualify it by saying public cloud, private cloud access to any kind of any real cloud? I think there’s some fundamental principles that we’ve kind of adopted over the last few years around how we package up applications for portability.


If most folks are familiar with the 12 factor application the common things that people talk about in those contexts are things like having a declarative model that you have a declarative way of defining what your application is doing. You have a portability, although portability last few years, I think it’s starting to become more pervasive.


For a while, people were locking themselves out, locking themselves into a single platform. And increasingly, you know, with platforms like Kubernetes and other sort of standards, things are becoming more portable across cloud platforms. Things like having some level of decoupling between the config and [00:04:00] the, and the build process, having a pipeline deployment model, continuous deployment, those are all principles that come hand in hand with sort of packaging applications and deploying them in the cloud platform.


But if you look at this from a security perspective, I think the last few years security is also slowly starting to move in that same direction. With a little bit of a lag. There’s always being a little bit of tension in security practitioners to obviously not let go of things that they’re familiar with.


But what, when you realize that your cloud workloads are now much more dynamic, the way people deploy applications, manage applications and take care of, you know, healer and failures as much more different, it’s increasingly important for network security and security in general, quite frankly, to also follow some of the same principles in terms of having again, try and make your security artifacts, declarative when possible ideally in lockstep with the applications that they’re protecting and the infrastructure that they’re protecting typically have a pipeline [00:05:00] deployment model with things like workflows on how you’re deploying things continuously,


so you’re not stuck with Gribble infrastructure. So to me, when you ask about what does that mean? I tend to. You know, think about this as security and network security, needing to follow how applications have evolved in adopting the cloud. So that’s sort of a very crude way of describing my general instinct there.


But again, look, everyone has no opinion on this, yeah. And


Ashish Rajan: I think I’m glad you mentioned it because to your point, how many applications have been able to go into the whole 12 factor mode as well. I still remember when I was in college university, there was the whole three tier architecture.


It’s like you have a web layer, you had an application layer and your database layer. And to a large extent, people are still used to that in a network context, because if you asked anyone, who’s my networking background. Hey I need this network for an application. Okay. So are you, what kind of zones you’re going to get into and talking about, you’re talking about zones.


How different is this to a traditional network?


Karthik Prabhakar: In the early days of my career, I sort of used to build a [00:06:00] network for a living . OSPF BGP across like hundreds of thousands of millions of devices connecting all of these intranets internets.


And with diff and back in the day, you know, used to have this wonderful concept of an internet. And then an intranet with a nice little perimeter, somewhere along the way. I think I’m dating myself, but you had this concept of firewalls come into play and you know, you had this nice as well. Exactly. And then as the commerce on the internet became more pervasive, let’s say people’s heads like, oh, we need to have a DMZ, the demilitarized zone where we put out external assets, but all the crown jewels are sort of tucked away behind this firewall.


And that mindset from a network security perspective has sort of evolved over the years. Where if you look at a lot of organizations today, they started decomposed that concept of a DMZ and internal into these things. Like, you know, I, I called them threat protection zones, where you have different classifications of saying, Hey, these are the crown jewels.


I’m going to collect them together. And this is on, I’m going to have a different zone where this business unit [00:07:00] can do business and they have the applications together. And so now. But fundamentally, if you step back and think about that, those at the still the perimeter protection model, where you essentially have, you you’ve reduce the, the, the impact of a breach to things within that zone.


Again, with the assumption that you have some very strict controls between zones. Now, the reality though is when you look at what’s been happening in cloud native applications, as they’ve gone through, as microservices, adoption has happened with Kubernetes overlays service meshes just even just vanilla cloud instances.


These days, the way people deploy applications is look when you’re deploying microservices, you might do a you do incremental deployments. You might deploy a Canary version are out 5% of your traffic to that train kinetic. And if the performance is good, start to gradually VIG back and all of these sort of decisions, I’m making your network connectivity within the microservices, much more dynamic.


So what might be [00:08:00] sort of a traffic pattern flying between these individual applications could dynamically change over time and any sort of brittle boundaries that you built in the center of your infrastructure around the zone. Generally speaking, they tend to struggle to keep up with the dynamism of cloud workloads.


So when you look at the concept of what does networking mean in these days, increasingly there’s sort of two ways to look at it. That is I I’ve, I’ve been observing. This is one there’s sort of. Physical network or the cloud network from a physical or virtual perspective in terms of, look, I have my different regions.


I have my different pools of clusters and infrastructure, and I have my networks there, but then I have my application networks, which is ultimately my, the sort of connectivity between these microservices. And they are absolutely leveraging that same cloud networking paradigms. They’re leveraging the networking within the clusters, but the connectivity is much more dynamic,


because this is ultimately [00:09:00] being controlled by an orchestrator that is taking your declarative manifests and saying, look, I will ask you to deploy five instances or five pods of this application, but if the performance hits a certain threshold, start to add, add more pods and the other pods could be in a different region.


It could be in a different, you know, so. This is sort of the new reality that we are dealing with in the cloud native world, in terms of networks, the network infrastructure, especially at the application level is much more dynamic. And so it has some very specific implications from a, you know, obviously from a network security perspective as well.


Ashish Rajan: I think is really interesting, man, because how you’ve mentioned the journey, that kind of applications I’ve gone through and I’m wondering people who’ve listened to them.


Some may be new and some may be going. Yeah. That’s, what we’ve kind of done in the past. And that’s where we moved on or continue doing in a cloud native world. I would love for them to get into some of the challenges that these people would face. Say, if you’re coming from where you and I were kind of raised in a whole traditional networking world where we had the three tier [00:10:00] architecture, 12 factor was not even a thing.


And now we’re going, I’ve got all this, I don’t know, hundreds of machines that are moving into a cloud, or maybe even a cloud native world. What are some of the challenges, maybe even the top three challenges from a security perspective that you think, cause we spoken about the change of mindset so far, .


You kind of have to think differently, but what are some of the obvious challenges you think that people would face? Like if I were to start building a cloud native environment today in cloud or not in cloud, maybe in on-premise, but what are some of the challenges I can face.


Karthik Prabhakar: There’s specific there’s challenges in adoption of individual technologies.


. But leaving that aside, I think if you look at this from a, I, if I look at the kinds of customers I’ve been dealing with, , which range from financial, the gaming to public sector agencies to whatnot, . As they adopt adopted sort of these new paradigms, bigger picture, I’d say there’s like two or three things that jumped to mind.


One is when you look at how organizations are structured in terms of different teams, you have security teams, you have networking teams, you have platform teams, you have application teams. One of the challenges when it comes to [00:11:00] security and adoption of these new sort of cloud native paradigms is.


In my view, separation of concerns and separation of duties between teams, because when you look at, when you have to deploy an application, typically the application team is knows the application. The best they can, you know, knows what kinds of access is required, but it’s the network team that needs to connect the network together.


It’s the security team that needs to potentially check off on the security rule sites that need to be allowed. And that the challenges, most organizations, I used to a sort of a traditional system where you have ticketing systems for firewall rules, for baths and whatnot, but in the new world, the challenge with back is the, the security team doesn’t know.


Doesn’t always understand all the nuances of the application application manifests change quite often. And so they have to rely on the application team to put the security controls. But if it gave all of these wonderful, you know, declarative security with, you know, policy, a score and [00:12:00] all of these wonderful features to an application team who was under the gun to get the product out quickly, the first thing they ask is where’s my allow all policy.


. Hello, Arabic. And, and so there’s this question baffled, because this is why a security teams come and say, well, we can’t trust the application team, so we need to review every application change. But the result of that is it causes friction and latency. And the problem with latency, especially with takes days, weeks to review individual rule sets, which often happen, that then causes the application team to go, oh, I have the approach this rule last week.


I’m just going to tunnel my new change through that existing rule and bypass the need to go ask for a new ticket. So it started causes all of these loopholes and security. As a result of this friction between organizations. So that’s sort of one challenge I’ve noticed is not having that suppression of concerns.


So you can automate more peace process. So that’s one second one, this is a common thing, which is, you know, both sides of the fence. People tend to hold on the things they know,


so there’s a lot of legacy [00:13:00] process craft, which hold people back a third one, which I’ve always, you know, I’ve been thinking about this a lot in some of the organizations and it’s, I cannot generalize it to big versus small organizations because I’ve seen dysfunctional small organizations and I’ve seen some big organizations that are, do things quite well, but sort of if you, if you envision this concept of a pyramid, , and the top of the pyramid is.


Sort of having a well-thought-out set of business, logic rules, governance, administration, procedures, and interfaces. And the second tier of that pyramid is a way to translate those, those business rules and logic into individual policy instantiations that define how you tag and label resources, how you define metadata, how you define policy that needs to be instantiated, how you define compliance rules, whether it’s internal compliance, and so that’s the middle tier where you’re defining the policy. And then the lowest key of the permit is [00:14:00] sort of the instantiation of the policy into individual platforms and individual cloud clouds into individual products.


And it’s important to have all three tiers of the permits of the permit. But what I tend to see in some of the more dysfunctional organizations is that they often are focused on the bottom of the pyramid, which is, oh, I’ve got to deploy on this cloud platform. I’ve got this product, I’ve got this firewall, I’ve got this rule set.


And they tend to sort of chase that tails in some way, because they’re chasing the latest new thing, but there’s not an overarching governance that defines why they are doing that. So it’s important to think of all of those. And I’ve seen, you know, this be done very effectively in some of the large organizations.


But I’ve also seen a lot of organizations not have that sort of thought through reason as to why they’re doing security a certain way and a certain platform. And that can be a very challenging thing to deal with. . So these are some of the things I see quite commonly in, in organizations today.


Ashish Rajan: Yeah. I think you’ve kind of gave three good examples men, because do you reckon this is also [00:15:00] because we need to challenge the way , I’m just going to use a couple of big names here, like say Bank of America or maybe more local to my place, like Commonwealth bank or whatever, these companies have existed for like 25, 30, 50 years.


And they’ve always followed that traditional model for it is a separate network team. This is a separate security team. Well, I guess initially it’s network security and security network was all in one, one batch, but now they separated that into governance and all that. For organizations that like the large enterprises of the world that have been doing this for a long time,they kind of followed that traditional model.


I’m thinking about people who are listening in to this going, oh, I’ve got 15 years experience of doing network security. You’ve kind of raised some interesting things as well because handing that control to a developer is probably not fair as well, because they’re not trained in like, Hey, this is how you do network security.


If you want to have two servers talk to each other, you probably want to have them in the same network. Like that concept is probably not taught to them.


And we’ve been able to kind of scale that, we still have global companies on that traditional network where it somehow [00:16:00] worked, and the policy changes that you’re talking about, Hey, I think I’ve heard more of that from a scaling perspective.


So are we saying. It’s easier to build if you have that pyramid structure and in a cloud native world, but scaling, is that worth more for scaling or like, I guess part of scaling,


Karthik Prabhakar: no, let’s even step back from that. . Because I think there’s some fundamental principles which are important to understand as you sort of migrate towards the newer architectural styles.


One is it’s increasingly important to have your security controls around the workload so that what you’re protecting is the asset, not where the asset is located. . Okay. And, and, and, and when you look at, you know, people talk about you know, all of the, the fact that you need to worry about authentication and authorization and being able to audit what happened,


so you have authen, artsy and audit, but people sometimes forget that the underlying primitive that drives the authentic. And the artsy and often the audit as well is having some notion of workload identity. And that is a critically important [00:17:00] topic because yes, you know, you can, some people can use IP addresses as, or DNS names as identity.


Those are weak identities, but yes, that could be a additional source of identity. But the challenge is what happens when things move around when things are dynamic and transient and, you know especially with things like IP addresses, you do have, you know, you do have, there’s no guarantee that, you know, an IP address can be changed along the way.


So when you talk about financial organizations you talk about network security practitioners, they’ve all sort of, they may have grown up in an age where they’ve built a set of rule sets and a firewall, and that’s given them years of experience on how to control these zones. But ultimately the world we are moving.


Is where, what you’re protecting is the asset and who that asset is allowing is being allowed to talk to it. And this is very loosely. The concept that Google beyond Corp describes. So if you have not familiar with the concept you can go ahead and Google it, which is this concept where what you’re protecting is [00:18:00] the asset itself, the workload, the service, the application with the level of authentication and authorization, I access controls, but with the appropriate identity that drives that.


And the, the sort of takeaway from this is that as your workload moves around, you should, your security for the workload should move with the workload. If your user is coming in from somewhere out in the internet and a web browser in an edge workload somewhere. As long as you have some notion of what that user identity is, ideally a strong identity, like a certificate or a job that just hung up token.


I actually, even with multiple factors of identity, you should be able to allow that user to access it service, irrespective of whether it’s services or a cloud or a different cloud or in a in on-premise environment somewhere. And, you know, being able to move things around should have no bearing on having to go, you know, rejuggle things in the middle of the network,


so interestingly, the mindset needs to be in the middle of the network. You [00:19:00] might want to have some cost strand protections, but you’ll find rate protections get closer and closer to the workload. And one last point, if I can make this way is with platforms like Kubernetes with service meshes, we finally do have the ability to decouple some of the security out of the application.


Into a layer just in front of the application. And this is a new paradigm the last few years, last 3, 4, 5 years that started given security teams a lot more opportunity to not have to actually get next to the workload, but still have that layer of independence from the application. And not in fact, most organizations haven’t most security organizations haven’t made that leap forward to benefiting from that capability.


. So this is sort of an interesting time in, in, in the space now.


Ashish Rajan: Can I ask you to kind of dig a bit deeper into this? Cause I think for me, I feel like that’s kinda like the, essence of what we’re trying to get through to, in this episode as well, where that is a different way of thinking about it.


Like, workload identity is a thing. It’s [00:20:00] not about IP addresses. I’m gonna go back to the example of an individual who may be working in a Bank of America, listening to this and going, it’s still the same, isn’t it? Like, how different could this be? Are we asking them to kind of like ditch the old networks, if someone comes up with them and says, Hey, I’m going to build a Kubernetes cluster here and should they approach me?


Well, we need to redefine how networking would work for that cluster and leave everything alone, or should they try and bring what they already traditionally do onto the new world? Like how would this, and maybe this is where if you can dig a bit deeper into the whole. I guess if you guys used to use the Cuban Andy’s example, how would I go about doing this?


Would I just go workload identity?


I’m listening to this and I’m sure people can Google the technicality of it, but the mindset that you were talking about earlier where, Hey, it’s about workload identity and now we have mesh networks, which allows us that next level of separation. Like what was it before and what is it doing now?


Karthik Prabhakar: I’ll sort of use a couple of examples, one is with platforms like Kubernetes, you do [00:21:00] absolutely have the ability to now associate a strong workload items. To your application. Specifically there’s something called spiffy.


It stands for secure production identity framework for everyone else SBI FFE, which is a way it’s a standard for how you would associate something like an X five and nine certificate or a jar, because the other standard that uses just Hungary token and associate that strong identity with your unit of deployment and Kubernetes, which is a part of your deployment,


and in effect, what that allows you to do in Kubernetes is every workload can get a strong identity and typically something like a certificate and what that means a service to service communications. You can now include the strong guess. And the benefit of that is it shouldn’t matter if your services more around essentially you’re building a trust and access controls based on the strong identity,


you could potentially compliment that with other things like things in Kubernetes as a concept called network policies, which allow you to create IP address based on dynamic IP address, based rule sets, which are [00:22:00] complimentary based on the Kubernetes labels. So based on the metadata of the application, the challenge is most organizations miss the steps to take advantage of some of these more advanced concepts.


Because they are, they want to get things working quickly. They don’t necessarily understand the concepts and whatnot. So the example I talked about where you can assign the X 5.9 certificate and spiffy certificate, typically in Kubernetes, you would do that by associating it with a service account.


Every deployment has an associated service account and you need to create, okay, I have this application, I’m going to give it a service account name, and then you can assign an identity. The problem is most deployments and Kubernetes don’t create a separate service account for every deployment, which means Kubernetes will say, look, I’m just going to associate you with a default service account.


And the pitfall of that is that if you have 50 applications, all using the default service account, they all get the exact same strong ideas. Which means the concept of trying to do access control amongst services disappears, [00:23:00] so there’s a sort of a checklist of things that sort of up number of resources available on how you go by building your run time, security controls, and Kubernetes.


And by the way, this is very distinct from config time and build time security controls, but for runtime, for authentic artsy, based on a strong identity, there’s a number of things that you can do that specifically rely on this concept of strong identity things like spiffy. And it’s the same also when it comes to client identity,


because obviously a Kubernetes clusters are not in isolation that serving a bunch of clients potentially on the internet. You know, it could be a service provider deploying 5g where it’s all web services hosted on Kubernetes. But again, As long as you have some way of defining what that client identity is like a jot like a, like a token, like an X five and nine certificate.


. Which is possible. You want to be able to leverage that across your infrastructure, across every service, all the way to data access. And one thing again, a common mistake I see in a lot of organizations is they [00:24:00] might do that authentication and authorization at the edge, maybe at the edge of the infrastructure at the edge of the Kubernetes cluster and leave things wide, open internally.


That’s good. That’s better than nothing, but in today’s world. I mean, there’s, you don’t, you don’t get points for it’s spirits sauce. It’s not it’s okay. Yeah. You want to do it properly all the way.


Ashish Rajan: I’m glad you mentioned that because I I’ll definitely recommend people check out kubernetes space because would you say probably that’s probably the more popular cloud native service from an adoption perspective that a lot of people might say face in their current environment at the moment.


I’m sure there are more services as well as a popular, but somehow Kubernetes has been on the radar for a long, long time. Now this make me also feel bad as those people who are listening and going, man,there is a lot of complexity around this, there is this whole policy has scored that I have to control the network and I have to do this.


So from that perspective are we asking them to develop a new skillset in a way, like what kind of skill set should the new security team should be looking at in their teams to be able to [00:25:00] say, deal with on premise, but at the same time, have this complex world of cloud native Kubernetes containers and everything deal with that


Karthik Prabhakar: I might take a step back again on this one, because look, products come and go technologies come and go, orchestrators, come and go cloud, you know, cloud services come and go, . And you might learn something for Kubernetes. It might be different for far gate or serverless.


So, whatever. . So to begin with, I’d say, actually, even before I get to the, I was going to say some of the things that people need to get grounded on is the fundamentals. Like what is an identity, you know, Get to know the basics, . And things like certificate management, what’s a certificate. You know what, when you look at the JSON web token, understand what the format is.


And then when you look at things like authentication and authorization, trying to understand what is being done rather than necessarily, you know, an individual product and how it does it, that you can learn later. But even before that, I’d say there’s one other thing, if you’re, if you’re looking at this from a valuing, a hat of a security [00:26:00] practitioner, a security professional, one thing I’d suggest is go work.


If you have the option, go work with an application team for a while, few months, few weeks, if you can, a few months, if possible, and live the life of an application developer and application owner if you’re an application owner, go work in the security team for a few weeks and try and understand how and why.


Sort of motivates each of these teams and what is slowing them down, but it also gives you an idea of what it takes to secure an application, what it takes to roll out an application to begin with. So that trust pollination of ideas is an important sort of underpinning. Now on top of that, obviously know the concepts you need to know.


And then beyond that, you know, there’s going to be cloud provided a specific instantiations of that, how you do identity AWS versus Azure versus Google cloud versus IBM, there’s going to be nuances, but as long as you understand the basics, you’d be able to understand the [00:27:00] instantiations and sorry, go ahead.


I was just going to say, just going to say a look and then, you know, wherever possible. Try and understand the, what will it take to make things faster, better? How do you get automation, ultimately products, whether it’s, you know, kind of like the company I’m advising economics where there’s, there’s a lot of focus on automating more processes,


building policies, machine learning, unsupervised, machine learning, all of that needs to compliment what, what an organization already needs to have as a skillset, . And a product, any product needs to come in with the ability to help automate and speed things up. But the organization needs to understand that the individual needs to understand why they’re doing it in the first place.


Ashish Rajan: Actually, that’s an interesting I love how you explained it as well then, because what we’re trying to get to is automation is obviously helpful and we definitely need to understand the identity pieces of how that has evolved from Hey identity is no longer just Ashish but from a networking perspective, as there’ll be of identities


The application didn’t just want release application, security wants to protect the same [00:28:00] application. Clearly the goals are still the same. It’s just about understanding what the other person’s perspective is. So using that as a premise of, Hey, we’ve cross-pollinated and I’m wrong, I’m not going to use the word DevSecOps yet.


What are some of the basic things we can start off with? Sounds like identity clearly plays a big role this first bit certificate management. So someone who’s listening to this and probably for non-premise world now, And realizes that they have a cloud native Kubernetes environment in their environment, or maybe is soon going to be part of a conversation where it’s going to be about Kubernetes. What are some of the basic things that they can have? Like you already mentioned certificate management, are there other things that you would, they can consider as good starting points to start building security?


Which in a way that it doesn’t come from the shackles of the on-premise network.


Karthik Prabhakar: We’ve had some transitions in the industry over the last many years, . Where we’ve sort of, sometimes I even questioned this notion of calling something on premise versus cloud in, and that sort of goes back to this mindset of on-premise or we have a, we have a firewall, we have an intranet.


So we are secure. Somebody [00:29:00] is like in 2021 that notion is, you know, look, every breach that happens. You always have to guarantee that, you know, there’s some assets somewhere that has been exposed. So even in the on-premise world, I think the fundamental principles still apply, which is that you are protecting the asset.


You have protecting access controls to, and from the, the workload or the service, but things like identity. Okay. This is where I tend to refer to things like strong identity, which is like an X five and nine, maybe a jock versus also, you know, you can also, in some cases you look at things like IP addresses or DNS names as identity as well.


The, but you do want to distinguish between where you use what, . So as an example, you needed the products in the market today that look at the fact that, okay, you, you have a workload running on this IP and that’s dynamic and you create a bunch of rules, which has. You also have products that go look at a, the fact that a workload is doing a DNS request for a given service.


And then what they do is they also look at [00:30:00] IP addresses associated with the DNS and then dynamically create firewall rules for that. A lot that are not the challenge is as you get to my pre-service patterns, like with things like the Envoy proxy, which is commonly used these days these proxies will allow the application a D do a DNS request, but when they send traffic, because they do load balancing at the client side, they dynamically change where that requests will go.


It could be to a completely distinct IP address. And so this notion of having some sort of control centrally that can go into the level of understanding which IP is, where that’s interesting when antiquated. The other example for that is


if you, if you, if you started to build these perimeter security controls, how you should ask yourself, what are those requests coming in for? Okay. This request is for this web service talking to disrupt service of a portfolio of three. So you great. You open up a firewall rule for portfolio three. What is, what is I doing?


What is, what, what good is that doing here? What happens if someone was a tunnel, some other [00:31:00] traffic through a portfolio for three WebSockets, you know tunnel going and exposing things to the outside, especially if you’ve got DLS one dot three. What are you going to do? So these are some of the questions to ask.


So what is the purpose of what you’re doing? And if you had the option to now have more finer grain controls next to the workload. Shouldn’t you take advantage of that. And this is where, when you look at platforms like Kubernetes, there’s a lot of options to help you make that shift. It’s the same in cloud platform, whether it’s, you know, whether it’s a serverless platform or other container based platforms as well, there’s increasingly options to allow you to get better security closer to the workload in a much more dynamic way, but it does require you to potentially we think what security means to you, especially network security.


Ashish Rajan: That’s making me also question what will you consider as a mature practice for network security obviously we can paint an ideal picture, but a lot of people may be looking for benchmarks for, I think I do good enough for security.


So from a maturity perspective, what would [00:32:00] you consider a mature practice of this.


Karthik Prabhakar: If you’re looking to see how you stack up, , again there’s two parts to it. One is how you stack up is irrelevant if you’re, if you hit by the next breach,


so you have to worry about is it is, have you protected your assets? Have you protected all of the things that you need to protect? Secondly, if you’re looking for ways to benchmark and validate, what if what you’re doing is sufficient. Look, there’s all of these standards organizations that built benchmarks,


you’ve got the CIS, a scientific net security that has the CIS benchmarks and they have it for different cloud platforms that Kubernetes. And if you look at platforms like Kubernetes, there’s open source implementations, like you bench that will analyze your configs. Actually, that’s a good point because again, look, some of these tend to look at your configurations.


So there’s config and build time. Artifacts that are validated by security. Then there is deploy time validation, things like policy governance. You could do OPA open policy agent covered. There’s a number of technologies that can sort of attach to it. Admission control when you’re [00:33:00] applying the application all by a pipeline and then does runtime security, which is what happens when your application application is deployed and then you need to validate and secure.


So there’s all of these benchmarks and tools that can do that. But I, if you’re looking at this from a sort of a little bit, it’s, I’m being a little bit facetious here, but let’s say if you, if you’re trying to make the shift from traditional to cloud native, and you’re wondering how I, how I built enough into my security structure, the thing to always also think about is have you encumbered.


Because if you have, chances are people are going to find ways around that. And that’s where the problem starts. And a good way. I I’ve I’ve used this example in the past, so, which is, let’s say you have a Kubernetes cluster with some applications deployed in a given cloud platform, could be a managed cluster or whatever, have a cluster and a different log platform.


Just take a workload from this cluster, redeploy it to the, a different cluster and measure how long [00:34:00] it takes for that re deployed application to go live. Measure time. It takes to have the redeployed application go be ready. . And it’s receiving requests and transacting things.


If you’re measuring it in the order of hours are more likely days, which is what most weeks in some organizations, because you have so much intermediate process, chances are, you’re doing it wrong. You should be ideally measuring it in seconds. . Where we’ll begin an application from one cloud to another, from one cluster to another.


From one part of the infrastructure to another, your security needs to follow the workload where you should also be confident that that security is sufficient. And that happens in a matter of it happens as your application transition. So your security always follows the workload and in the world we live in today, it has to be instantaneous, seconds and milliseconds and microseconds nine weeks and ours.


Ashish Rajan: No. And I think to your point, well, it’s a good standard to get up to, I guess identifying things in microseconds. But I would definitely be yeah. Interest in [00:35:00] learning more about this and maybe others as well. So w w where does someone would you say. People should upskill in cloud native skills.


Is that like, cause I’m sure people listening to this going, okay, what am I learning then? So I’ve got all this awesome information with garlic now, but where do I go and find like, what am I Googling for, I guess next, just to upskill myself.


Karthik Prabhakar: No, I have a great question as well. So there’s sort of two or three things where I’d say I’d suggest the starting points,


one is if you want to get a reasonably good sort of broad brush across some of the security, especially network security concepts that you should think about when it comes to cloud native security, I’d suggest going to the CNCF SIG security working group. And I, I could Google it. I’m sure I’ll find it, but they actually have they put out a few documents.


There is one document that. Which has a pretty broad stroke across, not just Kubernetes, but cloud native platforms in terms of the kinds of concepts you need to think about. And it’s not just focused on network security. They’re also focused on [00:36:00] build time, how you build things like container images, how you, you know, obviously security is a lot more than just scanning or config times security or deploy time, but they cover all of it.


And it’s sort of a very superficial, but it’s a very broad stroke across a lot of these technologies. Yep. Then it also provides a number of jumping off points to go deeper into more interesting concepts. So that’s one thing I would recommend as a good jumping off point. Also, it’s interesting that in the last year or two especially with the increased focus on cybersecurity within the us government, as an example, A number of government agencies, like the NGA, the DOD, they’ve all been publishing these sort of blueprints on what is security in a cloud native way, me.


. And sometimes they refer it to a more sort of psyche, harder to read NIS documents, national Institute of standards and technology, or but there’s a number of sort of concepts here. The risk is the more you read you’ll realize that there is a lot to read. And [00:37:00] this is where unfortunately, people tend to take shortcuts like saying, oh, I, I have a product I need to know.


Do you, do you meet the ASP top 10? . Which is the top 10 attacks commonly recently followed in web security. And if it meets that, then we’re good. And the reality is if someone is going to attack you, they’re not going to limit themselves to just those 10 attacks. Yeah. And so it’s really on to you, your organization, your consultants, and quite specifically everyone at the organization, from the application team to the security team to collaborate.


And this is where the, you know, this is why it’s such a hard problem these days, . Is and the reality and the sad reality unfortunately, is that the technologies have gotten more complex. And the number of moving parts are significantly more. So there is no easy answer, unfortunately to say, learn these five things and you’re done.


Ashish Rajan: Oh, but I think the, probably one, one takeaway from what you mentioned and probably this is still a hard thing to take away [00:38:00] is just to be able to talk to each other, like application team security team. I mean, I would hate to use the word DevSecOps for this as well, but I’m pretty sure it would be.


We’re like, yeah, that’s just that’s DevSecOps. But I think the collaboration. Because the traditional model kind of created a clear divide between security and applications, your point, having that understanding of what does it take to deploy an application in a cloud world? It’s very different.


The word you used to be on premise, there’s like so many moving parts to your point, IP addresses are like that. Very transient like this. So having a understanding of that probably is a good start. So that’s what my biggest takeaway from that. Hey, what should I learn? Talk to try and learn how to talk to your application people or the other way around security people for what it does it take to kind of achieve success?


Karthik Prabhakar: No, no, I shouldn’t. I, I, to me look, I’ve, I’ve worked with a number of organizations, including some of the ones who even mentioned the course of the, the podcast, some of the more mature organizations, especially the ones where they have the organizational mandate to allow people to flow between teams and literally [00:39:00] have to live in other teams.


It does two things. One is it builds more trust between the teams, and there’s, there’s this direct connectivity. And two, it gives, you know, you all putting yourself in the shoes of someone that has to do something else, . Even though you have to, your, you might be a security practitioner and you have to assure the security of your infrastructure or your application.


You cannot hinder agility. You cannot hinder, you know, functionality. All of you need to do all of the above . In internet. Yeah.


Ashish Rajan: Yep. Find a balance somewhere. Yep. Indeed. Awesome. Well th that’s pretty much what we had for this interview, man. But I do have a fun question, I’ve got three question.


So it shouldn’t take that long, but it’s just to help the audience, get to know you. It’s more around a, what do you spend most time on when you’re not working on cloud native technologies?


Karthik Prabhakar: Even in the last year and a half or so. I think the last year and a half has been a little bit of a reset for a lot of folks.


So going back prior to that, I used to travel a lot, just find random corners of the planet to go hang out and find, you know, put on a backpack and [00:40:00] go get into troubles, speak random languages. And obviously it’s been a little bit trickier recently. Hand-in-hand with her, I used to do some Latin dancing.


I used to, you know, there’s all kinds of interesting activities you pick up along the way, but I think this last year, a year and a half, it’s probably more staying grounded and reconnecting with family, friends often virtually. And it sort of makes you realize, you know, look there’s a, it makes you realize all the things you’ve taken for granted, which you can’t anymore.


. So I dunno,


Ashish Rajan: hopefully we get to a traveling and dancing once again, man, soon. Like, I mean, I guess you, you guys almost on the way anyways, so hopefully that’s the world does it as well. Thanks for sharing that, man. And what, what is something that you’re proud of? Maybe not on your social media,


Karthik Prabhakar: believe it or not, I’ve actually gotten off a lot of social media.


I still have to click on, I have a little bit but what, what, you know, look to me, the things which I’ve always be I always enjoy is, especially in a professional context, has been working with some of these organizations and these are [00:41:00] deployments, which are now mainstream, where it’s you look at.


Some of the, we’ve talked about financial working with some of these financial organizations where the, not just the commerce economies of many countries, many of the major Western countries, a defendant on the security and reliability of things like the Kubernetes platform and had a chance to collaborate working with some of these organizations and helping them sort of get from a state where they were sort of scratching the surface, trying to understand that to adopting it, and then being a advanced practitioner.


That’s wonderful having a chance to influence some of the early technologies to ask questions. Like why, why do you need this complexity? That’s, that’s a constant battle in our space, there’s always complexity working with organizations like for example, astronauts that I’m working with and be able to sort of challenge them.


To do better for users, so we provide users, not just with the advanced technology, but also help them consume it. Those are the kinds of things that, [00:42:00] for me, it gives me a sense of satisfaction.


Ashish Rajan: Yeah. That’s awesome. And it sounded like the Steve jobs kind of thing as well, since simplicity is hard as well, then it’s a great, great, like shows this, look at this amazing machine and what it can do, but like, is it easy to use?


Like not sure you need a manual to go through that. So now it’s a good example as well of things to be involved with then last question. What’s your favorite cuisine or restaurant that you can check?


Karthik Prabhakar: I, I I’ve really wish I could pick one. . It’s like people ask me like, Hey, what’s your favorite country?


Everyone is different. Yeah. I started private in the, in always changing things around. And then, you know, for me, I split my time between London and San Francisco. . The benefit of living in the city is you get. Like if I crave Luxor, there’s a wonderful Luxor place near here that if I crave Armenian food, if I crave Azuri food, there’s a place here and I tend to enjoy it.


All . So, oh,


Ashish Rajan: so, so you’re like, would you say you’re like a foodie then?


Karthik Prabhakar: Yeah. That, that term is so, so over-utilized these days I am someone that totally enjoys all kinds of food, . Because [00:43:00] you can, and I’m the kind of guy that look, if I, if I have a craving for gelato, I may just hop on a flight to go to Milan, to my favorite gelato place.


Ashish Rajan: I think being in the UK definitely would allow you to do that as well. That’s pretty awesome. And I think it, and having been so eclectic as well is, is, is, is a kudos as well, because I think I definitely find it. Food connects a lot of people and, oh man, if I can get an opportunity to try different kinds of outdoor did jump on the opportunity.


But I just wanted to say thank you for coming on, on board here, man, and sharing the knowledge with everyone here as well. Where can people find you if they have follow up questions about this world of network security and cloud native kind of world, where can they find you and connect with you to ask any follow-up


Karthik Prabhakar: questions?


A couple of options. Obviously you can find me on LinkedIn, but on Twitter, my handle as well. Yeah. So you can find me on Twitter. That’s one of the few social media avenues where I just, I spoke to your name and, you know, the other usual sources, like, you know, LinkedIn usually you can find me on, on, if you just Google me, you can find me on, you know, find my email and whatnot.


. So, yeah.


Ashish Rajan: Awesome. [00:44:00] And I’ll include them in the show notes as well, but thank you so much for coming in, man. I, I D I definitely enjoyed our conversation and I think we had about 50 odd people are watching this as well. So I’m sure they enjoyed the competition as well while anchors should leave either leave a comment or can reach out to you directly for a question, and we can come back to this, but thanks so much, man.


I, I, I feel like it was really good to talk about some of the, I guess, an unspoken parts of networking and like how suddenly I think a unit joked about this the other day, where, Hey, CCNA and MTSB and all those used to be like a thing. And now no one puts them in their resumes, but people, I mean, I guess if this still relevancy.


But I, I don’t know if that’s the number one relevancy, but I’m so glad we are kind of, at least got, gave those people apart to something maybe a bit more better future men. But thanks so much, man. I’ll I look forward to having you again and maybe in front of the topic though. No,


Karthik Prabhakar: first of all, let’s just thank you for doing this podcast because the content, the speakers, the questions you get, I mean, all of this is wonderful and I think this community, the more we can collaborate and share [00:45:00] ideas, which is what you’re facilitating, it’s, it’s going to make us all better.


So thank you for, for doing this.


Ashish Rajan: No, I appreciate that. I appreciate that. Thank you. And for everyone else I, you will I’ll feel on the weekend, which is our regular times for as well. We have a Brazilian specialists. That’s the hint for what’s happening this weekend, but I hope everyone has a good evening or good night and a good day, I guess, but I’ll see you on the next episode.


Thanks. Peace.