Extending Your Fortinet Next-Gen Firewall to K8S with Calico Enterprise

Good morning, good afternoon everyone. Again, thanks for taking the time to tune in today with all the craziness. Hopefully this webinar is going to be informative. Please feel free to raise any questions, and I’ll try to take them as I see them. Either address them on the way or leave some time towards the end to address them. So let’s get started with the presentation today. For today’s agenda, we’re going to be talking about our newest integration with our partner, Fortinet. Tigera and Fortinet have been working together for quite some time to offer this integration. I’ll start off with a quick overview of Calico Enterprise for those who are not aware of just Calico and Calico Enterprise and what we offer and what problems we solve. And then I’ll walk you through some of the challenges that we’ve seen with some of the customers that kind of led to us working very closely with Fortinet for this very unique integration. I’ll do quick demo for the solution. I’ll wrap up with some key takeaways and we’ll have some time for questions and answers towards the end. So if you’re not too familiar with Calico or Tigera, let me start by quickly introducing them to you. So with the [inaudible 00:04:18] and containers and Kubernetes adoption, one of the prominent projects that’s out there, is project Calico that fits in that CNI, the container network interface, so it’s one of the most ubiquitous CNI’s that’s used across hundreds and hundreds of thousands of projects out there. Tigera the company, is behind project Calico, so we’re kind of [inaudible 00:04:47] to them and the project itself, which of course is open source. We’ve known more than 150,000 known clusters out there today with a very active, collaborative and global community around the project itself. From a Calico Enterprise perspective, we take the power of open source at the CNI level, and we extend it to offer a full sweep of enterprise focus. That’s our security for Kubernetes and beyond, actually. So with extensive features that… Or for the enterprises to secure their Kubernetes cluster. Whether they’re on tram, or in the cloud or in the hybrid cloud. We have a wide variety of customers in the financial services, SaaS, and others that are using Calico as well as Calico Enterprise to secure their workbooks. So we have, basically from a Tigera and Calico Enterprise solution, we have three core capabilities that usually resonate well with the type of challenges that our customers are facing along their Kubernetes journey. One is about security controls. This is kind of how, at an enterprise level, you can enforce your security policies required for overall compliance across the board, especially if you have multi tenants from multi team, multi application running on the same cluster. Access controls, in terms of providing overall access to the different end points in the applications. Fine grain policies, and providing pod level access to external services. And overall, visibility and troubleshooting for network admins or selective apps, to have full visibility as to what is actually going on from a network perspective across the cluster. And that can be pretty powerful. So please remember those are kind of the three key areas why a lot of key enterprises are choosing Calico Enterprise to secure their Kubernetes networks today. So, in terms of where we can actually run, as I mentioned earlier, all the managed Kubernetes services today in the cloud base, whether we’re talking DKS, AKS, GKE, all use Calico for policy today. And that speaks to the confidence that our partners put in the product today. Of course, for also on-trend solutions like Openshift and Ranch, where you have the option to use Calico as well. So whether you’re deploying clusters on tram or in the cloud, Calico and Calico Enterprises can run offering a unique position to create policies and apply them, regardless of where your Kubernetes cluster is running. So, in working with our customers today and our users, we’ve seen… You probably have seen the files if you attended our meetups or sessions or Calico Con, or [inaudible 00:08:37]. But you’re seeing a lot of users and customers both have this kind of journey around adopting Kubernetes and micro service architectures. And starting from overall education around technology, to testing it and hand boxing it, to go through applying it with select applications, to production with a subset of the application, and then all the way to mass migration. We’ve seen various users come in, are in different steps. And we are basically seeing some common challenges and use cases that we’re trying to address. And we have been addressing, with our customers and users. To be specific, three key use cases are top of mind with a lot of you. One is around pod level access to external databases and services and APIs, which is a very common use case. You come up with applications that you have [inaudible 00:09:53] and you’re ready to move to Kubernetes. However, a lot of the tendencies network-wise and communication-wise, there is still a dependency for those applications and those pods to actually talk to… Extend those databases and services, whether they’re within your environment or externally across the unknown or the infinite. So that’s one use case. And securing those workloads to make sure when they need to talk to expand those services and databases, they’re actually doing it securely. And adhering to the compliance requirements that your condition may have is one key area. The other is along visibility and troubleshooting, as I kind of alluded to earlier. There is definitely a lot of uniqueness in just having a platform or solution that offers both the users, that is the application owners, the application developers who are actually using the cluster, as well as the administrators from networking, from security, to have full visibility into what’s going on. And since the CNI and Calico Enterprise come at a very unique place in the stack, we have full understanding and very detailed logs of every connection that’s happening across the cluster. And that is very powerful when we provide that level of feeling in power to the developers and the application owners, as well as the administrators to have over the [inaudible 00:11:20]. And troubleshooting capability across the clusters. And finally, in terms of implementing enterprise layer security controls, compliance and reporting controls, both provide the set security administrator. That power to have that uniform enforcement, all while also giving the power to the individual developers and application owners to come up with their own best practices and policies on their own. So that’s one key thing to remember. So, when we were working with our Calico Enterprise customers and our users, many of them have already… If you double-click on the first use case that is pod level access to external database and services, APIs, many of them have… Or, like the story, like the capability that Calico provides. However, they already have invested a lot of resources over many years into their existing fire walling infrastructure and security infrastructure, and they don’t want to lose that. You don’t want to be in the position of losing years of the security controls that you had in place to secure your application and databases and services. So this is what brought us to this partnership with Fortinet. So basically, the challenges that come up for customers, the Fortinet customers have brought up is, typically in traditional workloads, it was a very static kind of work in terms of you know that source IPs of the workforce that needed to talk to the databases, or extend the services so you created your policies, you implemented your security controls with that assumption in mind. However, we are moving to a very dynamic, very ephemeral world right now where containers and pods are spinning up and going down. They’re coming up and using different IPs all the time. They’re being launched in worker nodes, and that brings up the challenge of how you tighten the security without losing years of extensive experience around that level of security. So, in working with our partner Fortinet, we’re working on a multi-year plan for a very tight integration between Calico Enterprise and the Fortinet security fabric. In today’s work… And this is based on the latest reviews from Calico Enterprise, our version 2.7, we’re talking specifically about the first step that we took together in this integration. And that is integration between Calico Enterprise and FortiGate managers. But, rest assured that this is a multi-year integration developing that’s going to extend to also a two-way integration with FortiManager so that Fortinet users can create the security controls in FortiManager, and have Calico Enterprise will enforce it in the cluster. You’ll also see that we are working on integration with FortiGuard, so that any communication to bad IPs or hosts will be blocked at the source. And finally, we’re working also on taking all the autometry that we know, and created by the Calico Enterprise will also be populated by FortiSIEM down the road as well. But I want to double click on the uniqueness of what we’re doing today, that if Calico Enterprise is running across any Kubernetes crossover, whether it’s running on a public cloud or on-trend data sensors, you can now basically extend the power and the knowledge of what Calico Enterprise knows about your workload and Kubernetes services, and breach that and connect that with your Fortinet environment. And that’s one of the key takeaways from this session. So if we double click on the current integration, which is the first step in this journey with our partner, how we do this is we are… Calico Enterprise has full understanding of what workloads are being deployed with what labels and certain… Across your cluster. We have full visibility into the IP addresses, where they’re being put up, when they’re going down. And basically, as part of this integration, Calico Enterprise deploys a new controller that’s called the FortiGate controller that runs locally on the cluster. And it kind of watches for those different deployments. I’m using cloud native and Kubernetes native labeling scheme of you can basically have Calico Enterprise push those IP addresses and force IP addresses and node information to FortiGate, to create both address and address groups. So those are the only two things that we’re controlling in writing today. So that now you have… If you are FortiGate admin, now all of that information and data is dynamically populated for you so you can actually continue using and creating your policies based on that. So again, this does not require any manual intervention. The only thing that you need to do is map out all the… Basically, associate what application label you want to create with which address groups and blocks in Fortinet. And once you do that once, then the Calico Fortinet controller takes care of the rest and dynamically populates the FortiGate upstream so that you can have full visibility into those addresses, and you can create your own policies in FortiGate. And if we take a look, you’ll see that. You will start seeing with this integration Tigera managed objects in FortiGate. Again, we’re not creating any policies here in FortiGate. We’re not enforcing any policies. The only thing that we’re doing is managing endpoints. Basically, taking the endpoints from your Kubernetes environment and pushing them upstream so you have full visibility into the workload and associated source IDs from the workers that they’re running on. So this is an example of the application I want to use for my demo. But you can see that, in Fortinet now, you can see the addresses for the Kubernetes worker nodes, as well as association between the pods and where they’re running on the node. So you can create your own policies based on that. Or use existing policies, or just extend it to the pods that are running in Kubernetes today. So if there are no questions, I’m happy to jump into the demo right now, I think. I usually like to showcase the demo. I’ll keep it brief and to the point, but happy to take any questions that you have around this integration after the demo. So let me know when you see my screen. Actually, I’ll probably redo that. Just going to log into my FortiGate environment here and summarize for you what we have today. So we have this running in, I believe, on a public cloud today, demonstrating the full capability. And one of the things that we needed to do initially was just to create an admin [inaudible 00:20:11] API admin for Calico Enterprise so that the Calico controller that is running can also make API calls to create those optics. That’s one of the first requirements to be able to do this integration. But other than that, if you look at the address today, you can see that those are my two Kubernetes worker nodes. Worker one, worker two. And you can see here that we already have a handful of address groups that you’ll see how we’re going to be managing them, and how the controller’s going to be managing them in just a bit. Those are the services that are running as workloads, as pods in the cluster. And the source or the details, where they’re actually running, which worker, worker one or worker two. In this kind of demo, the idea is that if you already have a FortiGate policy, for example we want to allow a pod to go to and access resources on Microsoft, on 365. So they need to reach this [inaudible 00:21:26] domain name. This is how we’re actually going to do it. If you take a look at the Tigera site, if you haven’t seen the Tigera dashboard, this is a refresher. You have a dashboard that’s dedicated to informing you around everything around your network visibility in the cluster. It’ll have a histogram of everything that’s going on. And that’s why it can be very powerful, and not just only from a policy enforcement but also from a visibility and control perspective. This is the policy section if you haven’t seen that before. We offer a very [inaudible 00:22:09] and tiered approach to how you can create network policies so that you can have a way to uni formally enforce them, but also give access to the developers to create their own. Or user built-in recommendation engine to do so. One thing I want to highlight is that the endpoint… Those are all the actual pod IPs that we have. And those are only low-quality significant in the cluster. So your FortiGate is not going to be aware of those, but it needs to be aware of once the pod is actually deployed on a node, we need to make sure that that… FortiGate understands the traffic for this specific application is coming from this specific node. And that’s kind of the gist of the integration today. So, if we actually go back… Show you the slide before we talk about the demo. But we usually try to use a sample application here to demonstrate the capability. So I already have an application that’s composed of a front end, that’s in the DMD, two microservices and a backend. And they’re all running in the same name space, it’s called the Storefront. That’s the name of the application. And the idea here is that as we… With this integration, as we scale the application, we’re going to be specifically scaling the front end component of the application. We want to make sure that the policy that we created for this front end service that needs to access the Microsoft Suite is dynamically populated so that way, as we address more pod… You as an admin don’t have to recreate or change anything statically or manually in FortiGate. So, if we go back to my screen share, let’s take a look. Hopefully you guys see my terminal here. This is the application that’s running. You can see that I have a couple of services, specifically let’s look at the front end service here. We have only one pod that’s made up of four containers. But it is only still one pod. And [inaudible 00:24:40] worker one. We labeled this pod to be in the DMZ firewall zone, the DMZ. And that’s how we want to associate any pod with that label to an upstream FortiGate address group. So anything with this label, basically this was a pre-assumption how when we created the controller and the configurations for the controller to talk to FortiGate, anything with this label is going to be… Once it’s scaled, once it’s added to the cluster, it’s going to be populated in FortiGate. So just to remind you here, if you go back to the services, and we’re at the addresses, you can see here with this label, or the address group that is Kubernetes DMZ, since we only have one pod running on worker one, it’s going to only have worker one associated at the source VM, in this case, or node that’s going to be associated with this address group. So let’s try and key L this service to… Instead of one, let’s look at two. So as we scale the service, let’s take a look here and see if we can see that right here from the Tigera Calico Enterprise interface. We can see that both endpoints… So we have two pods right now running now on worker one, and worker two with the labels that we suggested. And now if we take a look, hopefully, demo gods… Let me refresh, because we have a thing at 10 or 30 seconds rule here. And here we go. So automatically, since we have two pods right now, one running on worker one, one running on worker two, automatically this address group was altered and was changed by the Tigera FortiGate controller. And now, any policies will adhere to respecting traffic coming from those sources, worker one or worker two. Now, you might ask… I’m sorry, one tiny thing. If we wanted to create a policy that said earlier, I already pre-created a policy… With the force of this address group, now it has worker one and worker two, and it’s trying to go to login.microsoft.com, it’s going to be allowed to. So that’s why you have full enforcement from the pod, all the way through your existing FortiGate infrastructure to access whatever resources that were implemented using those security controls. So, [inaudible 00:27:52] asked one last point here. Earlier Mike asked, what if you have multiple pods that are not part of this application, that are also running on those nodes? And I want to remind you that that’s where the power of having a multi-layered security approach comes in handy. Calico itself offers a very expensive policy enforcement, all the way in every node. It’s a distributed approach for both [inaudible 00:28:26] traffic. So let’s assume there’s another pod that’s running on worker one or worker two that is trying to go to login.microsoft.com. If it is not part of an application or label that is associated with our application policy that is defined, Calico will be preventing that traffic before it even gets to FortiGate. So, just a reminder that with this kind of multi-layered approach, you have positive reinforcement at ever node, in both directions, [inaudible 00:29:01]. You have a tiered approach on how you can actually enforce that as part of Calico Enterprise. But also, you have a way to continue enforcing that and extends that security model to your existing environment with a FortiGate environment with this integration, between Tigera, Calico Enterprise, and FortiGate. So with that, I wanted to keep it a brief demo of this integration. I want to remind you of the key takeaways of today’s discussion. If you were not aware of Calico Enterprise itself, hopefully now you’re more aware of us as a solution for securing your Kubernetes cluster, and helping you along the way to get your production and secure your production workloads. We are trusted by numerous financial services, medical, healthcare, web, [inaudible 00:30:06] companies today. With the latest Calico Enterprise, 2.7, now we actually have full integration with our partner, Fortinet, and their existing more than 400,000 customers as far as I know, which is a great partner to have to extend this capability to Kubernetes with this integration. Again, this is for both north south, as well as east west traffic right now. We have the capabilities to enforce policy without losing your existing investment in Fortinet environments. Finally, I think I mentioned this earlier, Fortinet has this Fabric-Ready Technology Alliance Partner, so if you go to their site, Calico Enterprise is now part of this program, and we’re really excited about that. Michael will talk about some of the resources that you have. Moving forward, if you want to dig more, there’s a solution brief that we can actually point to after, in the next slide. We have some time to answer the questions. One question was, how easy it is to migrate from OpenSource to Calico Enterprise in production. We actually have a whole section in our docs, I wish I can share them right now, but if you go to docs.tigera.io, there is a section on getting started to the left hand, it says “Migrate from Calico to Calico Enterprise” with specific instructions depending on different platforms. So I encourage you to look for that. I mean, we’ve worked with a handful of customers who were… Actually, most of our customers are already existing OpenSource users, and they went through the migration. So I encourage you to take a look, and it’s going to highlight the assumptions and requirements, and the caveat [inaudible 00:35:34] with the migration. Hopefully that helps. Another question is, “So if I were to create a new Kubernetes service and the service alongside with the pod IP, part of that service will be pushed to FortiGate. Is that the logic?” Yes. However, as I alluded to earlier, you don’t have to do anything manually when you create services or you create deployments or scale them to export this integration to work. However, there still needs a step between associating service labels or deployment labels, or overall Kubernetes labels to FortiGate address groups. So if you already have some form of a taxonomy mapping associated with what applications or groups or whatever it is you have in Kubernetes that you want to associate it with whichever address groups in FortiGate, you can do that once, and then depending on how you label your deployments, that will already be propagated to FortiGate automatically. So you don’t have to do it every time you create an application or software. Hopefully that helps. I have questions there, “Can you go through where you see the map in between pods, containers, and nodes again? Beyond visibility, what are the use cases of the integration?” So yeah, absolutely. Again, from Calico’s perspective, we’re very native to… And Calico Enterprise, we’re very native to the existing tooling around… The CLI tooling for [inaudible 00:37:20] is always a great tool to associate pods and nodes. But also, if we go back to the screen sharing, hopefully you see my screen. We have a view of the nodes, so those are the actual BMs, or in this case cloud instances that we are running with old information around them, in which old end points are sitting on them. But also the endpoints, in this case the endpoints mean pods. So you can drill down into the pods and see. In this case, you can use native Kubernetes labels, so for example if I want to see the DNV labeled “pods” there are two. You can see where they are residing. This is the full name of the pod. Actually no, this is the full name of the interface, the endpoint, that Calico manages. This is the pod’s name, which node it’s running on, the IP address of the pod itself, the Calico managed node, the name space, and the labels and policies that are affecting or de affecting this pod. So there are multiple ways you can get that information from CLI, from the Calico UI, it’s definitely up to you. All right, taking on the next. Yeah, sorry, so the second part of the question was, beyond visibility, what are the use cases of integration? Great question. So it’s not only visibility into FortiGate, you actually have a mechanism right now to use your existing policies and security measures in FortiGate for a Kubernetes [inaudible 00:39:12], that’s the idea. So you can protect your existing databases or environment, for traffic that is coming from Kubernetes clusters. So it’s not just purely visibility, it’s also about extending the security measures that you have today with this integration. Next question. “Is there a way to define policy between services running on a single node?” Great question. So, as I alluded to earlier, Calico policy… So Calico is both a CNI, so basically providing connectivity for the pods, but also enforcing policy and managing the policy in a distributed way. So the answer to that question is yes, but it’s being enforced by Calico itself. So if you remember when I showed the policy tiers, those are Kubernetes network policies and Calico network policies. So it doesn’t matter where the pod is running. Even if there are two pods, or there are two services running on the same node. If your policy says this service cannot talk to this service, and they’re both on the same node, then Calico itself will enforce that policy statically on the node itself. So the answer to that is yes. But it’s not done through FortiGate yet. It’s done through Calico at this point. Next question. “What is a recurring mechanism in case FortiGate does not respond to API calls within the time? Will Tigera keep retrying to make sure the policies are in sync?” The answer is yes. We do have a retry and pull back as well. And full logs, we can see and troubleshoot if there’s any issues with this integration. And you can also set up the retry or the polling interval on the retry interval, for this. The next question, “What happens if frontend is [inaudible 00:41:36]? Will you share the [inaudible 00:41:37] IP in addition to worker IP?” So, again, this specific integration at this point is for traffic leaving the pods, going and trying to access extended databases within your environment or internet services. So, for [inaudible 00:41:57] based security measures, you can have that enforcement, and you can also have the Calico level, but I’m not sure… I’m still unsure about the [inaudible 00:42:12] specific point that is made in that question. So please, maybe you can clarify as part of a different question what you mean by “Will you share the [inaudible 00:42:24] IP in addition to worker node IP?” Another question we have, two more questions. “Will a future phase of integration make it possible to push network policies from FortiGate to Calico policy? I understood that the current phase involves only FortiGate receiving Calico and [inaudible 00:42:43] details. That is the plan, to have a two-way integration so you can actually define policies in Fortinet manager, and actually have Calico enforce them. That is the plan as well. If you have specific use cases or specific ideas, and you are an existing Fortinet customer and/or an existing Calico user and customer, please reach out to us whether it’s here or through the Calico user group on Slack, or through the resources that Michael mentioned. I would love to get your feedback. Just another reminder that this whole integration was actually due to a mutual customer who needed this to actually happen, several customers actually. So we are actually very adamant about receiving feedback on what are the best ways for this integration, because we’ve seen a lot. So help us prioritize, help us shape this integration and provide that feedback. There’s a comment around the training. This is probably a question for Michael. “It looks like the training is already unavailable.” I don’t know if Michael, you can take that question. Yeah, last question, it was the clarifying question, I appreciated that you clarified. You mean the assigned [inaudible 00:44:41] balancer IP, where pod IP is an asset to this. The answer to that is no. Right now, the extent of the integration is populating the FortiGate address groups with the source IP of the actual DM or node that the pod is sitting on. Because again, Fortinet is usually a delay at where you want to protect… Well, with east west north south, anything that is leaving the node is south, or coming to the node. So that is kind of the extent of the integration right now. So there’s nothing specific to the node balancer IP, or any virtual IP integration at this point. Hopefully that answers your question. A great set of questions here, so thanks for that. So one more question that just came in, “Is it conceivable to leverage Calico Enterprise Fortinet integration when running Calico without Kubernetes? In other words, in an environment where we’re using Calico to provide security policy between VMs, both endpoints, not between container or pods?” Great question. So we do actually have that capability. Not the integration yet, but actually I don’t know the answer to that specifically. Right now, we do have that capability of using Calico without Kubernetes, just using Calico to enforce policy in a very consistent way. So if you have workloads running Kubernetes and workloads running on VMs, you can actually run Calico on those VMs. And you can create the same set of policies and have it enforced, both on the [inaudible 00:46:42] on the VMs. We do have that capability today, but as far as I know, and I need to probably have a check, as far as I know, the FortiGate integration specifically is looking for pods and pod labels, and not looking for just overall workloads that are not in containers. But I’m actually not 100% sure to that answer. Bye.