 Hello everyone, my name is Dan Willett. Thanks for coming to our talk where we'll be talking about running financial workloads in Kubernetes. Now, you're probably already familiar with what Kubernetes is and you've heard it a bunch of times. So we're not really going to focus so much on what Kubernetes is, but more about the specific challenges that customers face when they're taking financial workloads and running them on Kubernetes. And we're going to drive it by going through three real world examples. So a bit about me, I'm CEO and co-founder of ISOvalent and my background for the better part of the last 15 years, along with my co-founder, Thomas Graff, has been in Linux, networking and security, working in the kernel, working on technologies like OpenVSwitch. I was one of the founding employees of a company called NYSERA, which built OpenVSwitch and was later acquired by VMware to become VMware NSX. And hi, my name is Neela Jacques. Some of you may know me as the former executive director of the Open Daylight Project, where I was working with a number of large financials who are really keen to bring greater programmability to the network. Most recently, I was at Barracuda Networks working on more of the security part of the network. What I want to do is jump right in to tell you a little bit about ISOvalent, who we are, and then we'll dive in to the underlying technologies. So we are a Silicon Valley venture-based startup. We're very much an open-source company, and we maintain two really key open-source projects, as well as contribute to a couple others, and we'll talk a lot more about those in the presentation. To begin with, though, ISOvalent is most often associated with our flagship open-source project, Cillium. What is Cillium? Cillium is an EBPF-powered networking, observability, and security technology built specifically for the cloud-native world. So what is EBPF? Well, EBPF has been described as giving Linux superpowers. And what EBPF is, and we'll talk a lot more about it, is a way to securely embed programs into the Linux kernel. This is incredibly useful for things like observability, for things like tracing, as well as networking and security. We're also big believers in Kubernetes, and of course, that's why we're having this talk, and we leverage the Envoy project as part of our Cillium solutions you see in the diagram in the middle here. So I think just to start off this presentation, I think one thing that's clear to all of us is that the world of financials has been changing rapidly over the last few years. We think back, still we see it when we walk down Main Street, banks typically have these big, beautiful buildings, because in the old world, differentiation was really about assets and security. A bank is someone that you want to trust. Well, clearly that's still important, but really now the basis of differentiation for a financial has changed dramatically. On one hand, there's the breadth of things, and if you see if you go to the website of any major financials, almost every company out there has the ability to offer their customers a wide portfolio of offerings, but more subtly, it's also about how it presents those, how a financial is able to interact with its customers. Does it feel like an integrated way, or you've probably experienced going to some banks and finding that every tab that you click feels like you're dealing with a different company, with a different experience, with a different back-end application, and more and more, that goes from awkward to being, frankly, not good enough, and so we're seeing the world in which financials, the differentiation of financials, is now not so much about assets, but about software, and so to be able to walk this digital transformation journey, what we're seeing is financials have to build new capabilities, they have to build new applications, but that's also creating requirements for a new type of infrastructure. These new apps that we're creating, created need for us to be able to massively scale up and down. With what we're seeing in the world today, one piece of news can drive everyone to immediately go quickly check their portfolio, and you can go from having 5 million to 50 million to 150 million, all accessing the same underlying app that you have. We also need to rapidly change and adapt. The time that we get, for example, to process an acquisition has shrunk down dramatically, and our customers are now all over the world. Information needs to be centralized for privacy and many other reasons, but on the other hand, we need to be able to deliver an experience that is incredibly low latency for our customers, and so we need to place our services really close to our users. Kubernetes, as an underlying infrastructure, was really built in such a way that it can deliver very, very well on all of these requirements. So what is Kubernetes? Some of you may be very, very familiar with Kubernetes. There may be others who don't know as much, so I thought I would spend a little bit of time giving an overview of this real critical technology, and I will shamelessly borrow from another Linux Foundation family project, the CNCF project. They created this great illustrated children's guide to Kubernetes, and I'm not going to go through the whole guide. I urge you to go do that on your own, but I want to take a couple slides because I think they do a good job of illustrating some of the key concepts behind Kubernetes. So the first key concept of Kubernetes, or what has really enabled Kubernetes, is a shift in the underlying construct by which we deliver infrastructure. Historically, for the last 30, 40 years, we deliver infrastructure from a server, and while more recently that server has gone virtual from the physical, we're still really delivering a server with an operating system that is incredibly heavy, and that has led us to a more monolithic way of developing applications. Over the last few years, there's been a huge surge into the use of a container. What is a container? It's a much more lightweight construct to put in an app. It allows me to be able to encapsulate a set of logic, a piece of a service, in a way that it's very easy for me to spin up and spin down, very easy for me to scale up and down, and as part of doing that, I'm going to make that construct stateless. So in so many ways, containers are fundamentally changing the way we deliver infrastructure, but we have to recognize that the move to containers has created a whole set of needs. We need to think about how to manage these containers. We need to think about how to network them as they're coming in and out. They need to be scheduled, distributed. We need to load balance, obviously, around them. It's a much better way of delivering things, but it also creates a new set of requirements. And so Kubernetes really came in to be able to solve that second set of challenges, and really what I think Kubernetes does so well is it shifts the entire paradigm from thinking about delivering an app via a server, is the idea of let's turn it around, really think about a service. I'm trying to achieve something. So for example, a shopping cart. A shopping cart is a great example of a service. We understand exactly what it's supposed to do, and then the delivery of that is just really a matter of scaling towards the demand of a customer. I can create a service and that service can be instantiated in a series of containers, and then as I need to scale up and down, I just go ahead and fire up more of these containers, or I can go ahead and shut them down as people go to sleep. And so a service is a much more logical and better way to be able to think about delivering an application. This is really what Kubernetes is all about. Dan will be going into a lot more detailed in this in a second. But let's talk a little bit. I mentioned one of the challenges in this world where we've now got thousands of these containers that are that are delivering our applications. One of the challenges of this is being able to network them. And when we think about networking, we certainly think about connecting them. But you also have to think about, well, what happens when something goes wrong? How do I observe whether all the right connections are being made? Because we've all had that situation of having that spinning circle as for some reason an application is not being responsive. We also have to make sure we have to continue to make sure that all of our communication between our services as well as between our services and our customers remain secure. Now for 30 years we have evolved an entire market around one specific way of delivering this this monolithic architecture we were we were talking about. And you know in in the old world we really thought about a server and protecting that server and protecting a customer's access in and out. Our security and connectivity was really about hardware devices and and most of the time it was about hardware devices that sat between the end customer and the underlying infrastructure. Kubernetes, the Kubernetes architecture, undermines this model at every turn. IPs may be being created and destroyed every minute of every day. Change is constant in that environment. In terms of the bulk of communication it's no longer user to infrastructure primarily, what we call north-south, but more and more communication is happening between these different services as we've taken a complex application and broken it into a bunch of smaller parts in terms of a bunch of different services. And so our ability to connect to observe and to secure our applications has fundamentally changed in this new infrastructure. And so where we are today I think is actually very interesting. We have, thanks to Kubernetes, thanks to thanks to containers, we have a far better infrastructure. Linux itself is becoming the the strategic technology of this world and this is especially true for networking. Unfortunately the first generation of networking functionality that was built into the cloud-native Kubernetes world really sought to replicate a lot of the concepts from a prior era. It has a whole set of challenges which Dan will go into in a second. And so we realize this is what we're all about at ISOvalent is there's a need to reinvent networking, to reinvent network security from a cloud-native perspective. EBPF is a foundational technology that really allows us to do a whole set of things that weren't possible before and we have built Syllium leveraging these superpowers that EBPF gives us to be able to build a new networking observability and security architecture built for the cloud-native world. Cool so thanks Neela. Hey folks it's Dan again. I'm going to jump in and do what I consider at least the fun part which is getting into the core technology and getting into the customer use cases which is really what I think what really matters at the end of the day. So first off just one quick slide so that we level set a bit in a bit more detail around why some of these networking challenges exist in a Kubernetes world. So in Kubernetes you have you know Linux workloads often VMs but they can be bare metal right and these Linux workloads essentially are managed by the Kubernetes control plane to create a pool of capacity where individual lightweight containerized workloads that Neela was mentioning before can be scheduled in a highly dynamic way. You know these physical these these Linux workloads are connected to an existing network that's how they might reach out to reach legacy servers and legacy VMs or get to the external internet but they also communicate amongst themselves. And when you know you need more capacity let's say you're scaling up some of your workloads you're just going to throw in another one of these Linux workloads it's going to be managed by Kubernetes using the kubelet which is the agent that runs on each Kubernetes worker node and you know more pods are going to get scheduled to this. And so again the key things to to realize here is that you have a dynamic pool of Linux workloads with multiple tenants workloads being scheduled there you know they're getting assigned IPs they're being destroyed they're getting new IPs it's a very dynamic environment. And it's connected to your physical network but your physical network isn't really aware of what is going on at the Kubernetes layer and as we'll start to jump into some of the customer stories in the next couple slides you know you'll see that that is a really pivotal point in terms of achieving a lot of those requirements that financial enterprises have have always had. So let me jump in to the first user story. We're specifically modeling this on a large US bank but to be honest with you this is a pretty universal requirement for a lot of our enterprise customers it's just probably most extreme within financials and and other entities that have a ton of compliance requirements. So I think the key thing to remember is that you know all of those compliance requirements this is an example of the PCI you know requirement but there's other things like Sarbanes, Doxley, etc. You know these don't go away simply because you're using Kubernetes. You know so you know obviously a first requirement here is the ability to isolate you know a app that may have sensitive user data from another app. This is pretty obvious this is kind of network security 101. Why is even this something so basic difficult in a Kubernetes world? Well let's imagine you know we want to say hey tenant A should of course be able to talk to other tenant A workloads and also you know reach out to payments.com. Tenant B should be able to talk to other tenant B workloads and maybe reach out to a database in your legacy infrastructure and tenant C should only be able to talk to workloads you know from tenant C. These are pretty simple you know not mind-blowingly complex isolation challenges that you might need to do to meet your basic security compliance requirements. But the problem is you know traditionally what would you do you put tenant A on a VLAN, tenant B on a VLAN, tenant C on a VLAN and use a traditional physical firewall to isolate them. But the problem is twofold actually. First off you know physical firewalls that are seeing this traffic that has no idea if the traffic for example on that first Linux worker node came from pod one or pod two. So how does it know what that traffic should or shouldn't be able to talk to? It doesn't understand the identity at a Kubernetes layer of the workloads when it's seeing packets out the network layer. The second one is also pretty obvious from this diagram right if pod one is talking to pod two there it's never even going through the physical network it's never going through your physical firewall. Therefore a traditional firewall would not even see this connectivity even at a network layer. So it's pretty clear that kind of even the basic multi-tenancy requirements that you need for compliance can't really be met with traditional firewalls in a Kubernetes environment. So what can we do here? Well Kubernetes has a construct called network policy. Network policy is a way of defining network connectivity and restricting network connectivity inside of a Kubernetes environment in a way that isn't based on IPs because those IPs change all the time you'd be constantly updating your firewall rules you know you'd lose all the agility benefits of Kubernetes but instead based on higher level identity where you can say for example in a declarative policy you can say tenant A workloads should only be able to talk to other tenant A workloads and talk to www.payments.com and then wherever those workloads end up getting scheduled in this case Cilium we're using Cilium to implement network policy you know will program EBPF in the Linux kernel to make sure that wherever tenant A workloads pop up it has exactly that type of access and no more and because Cilium and EBPF are running inside of the Linux kernel on each one of those Kubernetes worker nodes there is no network connectivity even network connectivity within a work within a single Linux worker node that isn't seen and managed by these security policies. So first takeaway is firewall policies still need to be applied inside of a Kubernetes world and network policy is a Kubernetes construct combined with a CNI plugin like Cilium that lets you achieve that but this user story isn't done. This same bank has not just firewalling requirements but also security visibility requirements to meet their compliance right you know you've probably seen requirements that say hey you must be able to monitor and log all at all network access to systems with sensitive data you have the exact same problem you have in the firewall world if your logs just contain IP addresses how do you know who is accessing what sensitive systems right those IP addresses don't actually tell you what workload and with what data you know something was potentially accessed similarly your requirements your compliance requirements might require you to be running intrusion detection well you could run intrusion detection for all of your workloads north south but how do you ensure for example that only a select set of apps have intrusion detection enforced if there are compliance requirements dictate that and that that intrusion detection even sees all of the service to service communication between them it's essentially exactly the same problem for firewalling just in a visibility context so you know again the traditional IP import based logs don't give you the visibility and any network monitoring capability that isn't fully distributed will not give you that capability so again you need something that is a running inside of every one of your Linux workloads right and that sees every bit of traffic that is going between the workloads and sees it not just at an IP level but sees it in a way where those logs can include you know detail about exactly what kubernetes service was communicating at that exact time and that's really the power that you get with a platform like cilium and ebpf is that you're able to get all of your network audit and network connectivity information exported into for example the sim that your sec ops team uses like splunk or elastic or whatever else maybe arc site you know and you're able to get that data but in a fully identity aware way such that if your security team comes back three weeks later and says hey this IP address from your kubernetes environment did something suspicious you have the full audit trail there of oh i understand what team service that was at what time if it is determined that that service was compromised i can tell maybe how that attacker moved land early within the organization what information the attacker may or may not have gotten access to so that wraps up user story number one user story number two is another security centric story probably not a terrible surprise given how important security is to the financials this is actually from a startup who is a pain in the payment space um they migrated their app from an on-prem data center where they had strong kind of guarantees about physical security um to a cloud data center and as part of that they were trying to understand how they could get stronger guarantees about encrypting traffic in transit um as obviously there's a lot of sensitive payment related data um that was being transferred between their different services and from their services to various payment gateways um that that that that they integrate with so of course the traditional way that you would encrypt data in transit would be at the application layer your application developers would you know build their applications using for example tls and um you know rely on encryption at the application layer now that's fine and it's secure when done properly but there's a couple downsides to that you know first off if you initially built your application assuming it was an environment where you didn't need to worry about encryption right but now as part of your cloud transformation for example you are now moving to an environment where you do need to worry about encryption right you now have to go back to every one of your application teams and go tell them to change how they've built and run their apps to um to add encryption the other part is that even if they did add encryption you don't necessarily know the choices of encryption ciphers tls version ciphers etc that they that they've chosen so i don't know how many of you've seen this i know i got several emails like this recently you know there's a basic deadline for pci compliance that you have to have moved off of older versions of tls and that that that they'll now be fully deprecated um this article is from july i feel like i got several emails in the last couple months about this from from different um the sass providers um basically saying tls older versions of tls will no longer be supported so now what what happens here is you have to go and tell all of your application developers hey to continue to be compliant you have to go update all of your apps and well it's certainly possible it's much easier if you just have kind of a easy button um that you can transparently apply these more stringent security requirements to your application and that's what's actually possible in kind of a kubernetes world with something like cilium is that you're actually able to just declare say hey workloads from these sets of pods right should always be encrypted it doesn't matter what the application has done in the linux kernel itself add the encryption on top of the underlying communication and so what that gives you is not only saves your your development team's time but also from the security perspective gives you a lot of certainty you know for sure that all of that traffic is encrypted um you know exactly what encryption parameters were used to encrypt that traffic and so you know this is i we joke we have one of our customers used to call this boom encryption because you set it once and boom it's everywhere as opposed to having to go team by team by team trying to nag and corral them to kind of being fully compliant and then realizing that at any moment they may deploy a new part of their app that is no longer compliant and you have to continue to track them down so transparent encryption is kind of a new model of thinking about moving those meet the the work needed to meet those compliance requirements to the infrastructure layer rather than solving it in each individual app right another last one is actually a combination of two different user stories one is a large us insurance provider and the other is a europe-based um financial payments company and i think there's an old joke that i think it's in real estate there's only three things that matter location location location um i think in financial services software you probably say well there's security but location location location as well you know there's several examples nila already touched on this first one which is often you know you'll need geographic proximity to an exchange or to another financial api to reduce latency of a transaction but there's also tons of requirements around data residency right you know if you're a global financial institution you'll often find you have to store the data for your customers in germany you know in germany in germany right i can't tell you the number of financials that are saying well i'm going to either do you know i'm probably going to have alibaba as a cloud at some point because i'm going to need to do work in china right so you're kind of almost inherently if you're a global financial biting off these um types of data residency requirements and then the last one this is particularly relevant i think for the insurance company but it's probably relevant for for all the financials is fault tolerance you need to know that even and probably especially you know if your data center which might be in your home region is knocked out you still have other locations um that are fault tolerant you know if there's a hurricane that hits hits your home area where your your primary data center is and that's exactly when your clients are going to be filing claims and wanting to check in on their policies and you need to be able to make sure that that you have that that fault tolerance built in so you know the key challenge here from a kubernetes perspective is that you want to be able to still apply those security policies that you had in place but now these workloads aren't in the same cluster but you don't want to expose for example a service in your primary data center you know to all other workloads in your internal network just so you know a kubernetes cluster in your trading one location can access it right that's not at all least privilege what you want to be able to do is essentially have those find those same fine-grained zero trust policies even for workloads that may be spanning uh different different geographic regions for any of the reasons that we talked about in the last slide so the answer here is to kind of create a mesh of the kubernetes networks cilium has a feature that can do this called cilium cluster mesh but essentially you want it to be a single fabric from a network identity perspective so that when a packet arrives at your primary data center you know you can tell that it came from tenant c and should be allowed to go to a tenant c workload but not a tenant b workload or a tenant a workload the same thing applies to those security security visibility requirements we talked about right your logging needs to be able to log and understand that hey service a was talking to service b even if service a and service b were in different geographic locations and so really you can kind of think of this last aspect of as being able to preserve the critical identity for security enforcement security visibility even despite you know these these kind of requirements of financial workloads to often run in different geographic locations cool so just to wrap up we talked about three main user stories we talked about the need to be able to meet the core finance you know firewall and security monitoring requirements that financials face by adding an understanding of kubernetes identity in a world where ip addresses have become meaningless we talked about being able to you know add transparent encryption to be able to meet encryption requirements when for example a workload moves from a you know maybe on-prem environment where encryption wasn't critical to a cloud environment where it now is critical and for user story number three we talked about being able to guarantee these types of properties in a secure way despite having these amped geographically distributed as is required for many reasons in in the cases of financial services software so with that i want to thank you for your time i want to encourage you to check out learn more about ebpf and cillium if that's interesting to you we actually recently just hold hosted a virtual conference of ourselves the ebpf summit and we had um capital one talk there which will i think resonate with a lot of the user stories i just talked about above so i'd encourage you to check out that video it's only a five minute video so really easy easy to talk or easy to to take in and then um you know we'll be live on the conference chat if you want to chat right now or um you know always feel free to reach out to nila or i on twitter and if you want updates around the cillium um feel free to follow cillium project on twitter as well all right so thank you very much for your time i appreciate it thanks everyone