Extending Your FortiGate Next-Gen Firewall to Kubernetes

 

Companies are leveraging the power of Kubernetes to accelerate the delivery of resilient and scalable applications to meet the pace of business. These applications are highly dynamic, making it operationally challenging to securely connect to databases or other resources protected behind firewalls. Tigera and Fortinet have joined forces to solve this operational challenge. With the combination of FortiGate Next-Gen firewalls and Calico Enterprise, you gain full visibility into the container environment and can define fine-grained policies to determine which Kubernetes workloads are allowed to talk to the enterprise’s crown jewels running outside the Kubernetes cluster. In this webinar, you will learn how Calico Enterprise and FortiGate enables you to:

  • Implement network security control requirements in Kubernete
  • Dynamically populate Kubernetes objects in FortiGate to enforce security policies
  • Gain deep visibility into network traffic within your Kubernetes clusters.

After this webinar, you’ll also understand why Calico has been chosen as the preferred network security solution by the leading managed Kubernetes services – Amazon EKS, Azure AKS, Google GKE, IBM IKS, and more – as well as powering several of the world’s largest Kubernetes clusters.

John: Good morning, good afternoon or good evening depending on where you are. Welcome to the Fortinet Tigera Next-Generation Firewall to Kubernetes webinar. We’re just waiting for some additional attendees to get logged into the platform. We’re going to pause for a couple of minutes here and allow them to get settled in. (silence) While we’re waiting for additional attendees to get logged into the platform, because we have quite a number today, here are a few housekeeping notes. On this webinar platform, there is a window where you can submit questions. If you do have a question, go to that window, just type it in there and our presenters will be able to access those questions. We will answer all questions at the end of the presentation. I expect that will be about 50 minutes into the hour here. So please make use of that questions window and we’ll get to those at the appropriate time. I think we’re going to start things off here now. Again, welcome to our webinar today, “Extending Your Fortinet Next-Gen Firewall to Kubernetes with Calico Enterprise.” John: I’d like to introduce Nico Kabar who’s a senior solutions architect with Tigera. Nico has a lot of deep experience in networking and Kubernetes including work at Docker and Cisco. And he’s very much involved in Kubernetes networking and security in the cloud. Nico?… Nicola Kabar: Thank you, John. Hello everyone. My name is Nico. I’m a solution architect at Tigera, really excited to be talking to you today with my colleague, Ali from Fortinet. We have a good session covering some key network security areas out on the Calico Kubernetes networking and security and, of course, Fortinet. As John mentioned, I spent most of my tenure along the intersection, as they call it, between containers, Kubernetes, networking in the cloud, and pretty excited about our webinar today. So I’ll pass it now to my colleague, Ali. Ali, you want to go ahead and introduce yourself? Ali Bidabadi: Thank you, Nico. I’m Ali Bidabadi, director of cloud architecture at Fortinet, been with the company for about 18 months. My area of focus and expertise is in the cloud and SDN platforms. I’ve been at different companies from Cisco to Juniper and Intel focusing on virtualization platforms, building cybersecurity solutions in the cloud, different platforms and virtualization platforms, as I mentioned. I’m very excited about this webinar today. I would like to walk you through some of the work we have done jointly with our fabric-ready partner, Tigera, throughout this presentation. So I’m very excited about that. With that, I would like to give you a quick overview of our agenda for today. Basically, we are going to talk about Fortinet, a little bit overview of what we do in Fortinet, maybe spending a few minutes on that. And then I’ll ask my colleague, Nico, to give you an introduction and quick overview of Calico and Tigera. After that, we will discuss some of the Kubernetes network security challenges that we see in the industry, the overall trends and the main pain points that our customers have. And then we’re going to focus on the join solution that we have developed to address those pain points. After that, we will spend a few minutes, maybe five to 10 minutes doing a live demo of the solution, of the integration that we have. And at the end, we will present you a recap of the presentation and some of the key takeaways. Of course, that will follow a Q&A session, that we will take your questions and try to answer depending on the amount of time we have left at the end. A little bit about us, Fortinet, I know that most of you know about us, but just maybe it’s worth spending a few minutes in case you don’t know much about Fortinet. The company was founded in 2000. We are the number one cybersecurity company in the world. We are the most deployed, by far, 2X unit shipment over our closest competition overall. About 30% of all firewall VPN appliance shipped worldwide, globally are from Fortinet. Most validated by far, recommended in nine out of nine NSS labs. Also, we’re the most patented, 3X nearest comparable cybersecurity compared to a company, number of patents that we have. We also have the broadest portfolio, the most integrated and automated coverage of the entire attack surface. We’re also very organic, dev-driven, that we focus on innovation, and I think the number of patents speak to it. As I said, we are very focused on our R&D. We heavily invest in our R&D, and we have been issued over 660 technology patents which is more than 3X our nearest competitor. With more than 45 or 455,000 customers, as I said, about 30% of all firewall VPN appliances shipped globally, we are easily the most deployed network security solution in the world. And we protect about 70% of all Fortune 100 companies. As most of you know, Fortinet Security Fabric enables digital innovation and helps protect every edge in your infrastructure. We focus on four pillars when it comes to our Security Fabric. First of all, we provide comprehensive visibility and protection across all devices, users, endpoints, cloud, SaaS and infrastructure, basically covering the entire attack surface. The main pillars, the key components that we have are, first of all, is network security, at the core of the platform, is the network basically, which remains a critical piece. Our security-driven networking provides secure, high-performance connectivity between all users and applications and devices and in the cloud. Then there is our zero-trust access network which enables identification of all users, applications and devices on and off the network. Our dynamic cloud security, which is the focus of today’s presentation, I kind of note, tend to put the Kubernetes also as probably the overall dynamic cloud security. I think it makes the most natural sense. But basically provides protection across all cloud environments including hybrid, public, private cloud and different platforms including Kubernetes. Our cloud security solutions including the virtual appliances and hosted solutions extends the core capabilities of the Fortinet Security Fabric platform to provide all businesses with the same level of cybersecurity and threat intelligence in and across cloud environments that they receive on their physical networks. And last but not least, AI-driven security operations provides faster response and remediation including actionable, customized, threat intelligence and insights. Now, let’s talk, spend a few couple of minutes discuss about our dynamic cloud security vision. Basically, it’s all about securing every cloud whether it’s a private cloud in your data center, public cloud deployments or your SaaS applications. As I said, that includes different platforms such as Kubernetes. And really, when it comes to security of your cloud, we look at three different areas, protect your cloud from a network security standpoint regardless of the traffic direction or where it runs, whether it’s in the cloud platform, in a containerized environment inside a cloud platform or Kubernetes, is going to be the focus of today’s presentation. Regardless of that, we basically want to make sure we protect your cloud, your environment from a network security standpoint. And then protecting web applications, whether they are accessed via a browser or API, which is becoming more common, of course. And the other area that is an important part of our dynamic cloud security strategy is securing your cloud platform from a cloud security posture management point of view, to help customers mitigate misconfigurations and help them stay in compliance with the compliance requirement. The other aspect of dynamic cloud security is about streamlining operation. Our Fabric Management Center provides a single-pane-of-glass management to help customers maintain their security posture across different clouds and gain full visibility into all of their deployments. And a more relevant topic, our fabric connector is where we connect natively to different cloud and Kubernetes platforms. We pull objects based on certain filters and metadata. And based on that, we can create and enforce certain security policies. So instead of relying on IP address, which is, as we all know, is very ephemeral in the cloud and specifically in Kubernetes, we tend to rely on a more persistent construct such as types of metadata or labels. And based on that, we have a notion of a dynamic address object that we can group those assets together and apply policies to those resources in a very dynamic fashion, which means if you have a new pod in your environment or a new VM that come up maybe five minutes later, we automatically resolve that in our back end to IP address without exposing it. So the whole thing is automated. If you have a pod that’s terminated, 10 minutes after that, the same process. We basically automatically remove it from dynamic address object because we don’t really rely on IP address even if that new pod or new VM comes back up online with a different IP address. Because we don’t rely on IP address, we rely on the labels, it basically becomes much easier for us to apply security policies consistently. Before we jump right in, let’s look at this interesting data coming from RightScale 2019 State of the Cloud report from Flexera. It shows use of both container and Kubernetes have grown significantly. And as you can see specifically, the adoption of Kubernetes has increased by more than 20% in only one year. And it really is just a testament of the trend most of us have already seen. As a leading cybersecurity company, we have developed solutions jointly with our fabric-ready partner, which we’re going to talk about extensively today, to help customers protect their Kubernetes clusters from a network security standpoint. With that, I would like to hand it off to my colleague, Nico, so he can walk you through an overview of Project Calico as well as the company, Tigera. Nicola Kabar: Thank you, Ali. Let’s switch over and talk about Calico and Tigera. For those of you who are not familiar with Calico itself, basically, it is an open source project. It started as an open source project back actually when Kubernetes was launched. We helped drive the CNI spec and became pretty ubiquitous around the Calico being adopted as a CNI for both container and cloud networking as well as policy. There’s more than 150,000 known clusters out there that are powered and running mission-critical applications today, as well as for both, as I said, policy as well as pod networking. So that’s it from a Project Calico perspective. Tigera is the company behind Project Calico. We actually invented it and maintain it. And we also have a set of enterprise … the enterprise platform that is called Calico Enterprise that basically extends the power of the open source Project Calico with additional features and functionalities for the enterprise. Calico can run pretty anywhere, on-prem, in the cloud, on managed Kubernetes services like EKS, GKE, AKS and IBM Kubernetes Service as well as other on-prem or self-managed Kubernetes services like OpenShare, Transfer or even upstream Kubernetes. We’ve been selected as the default CNI for many of those platforms. And all the four major Kubernetes services, the cloud services have chosen and have been using Calico for policy enforcement for Kubernetes network policies by default. So this gives you a holistic kind of view of where you can actually use Calico, and that is pretty much everywhere you can run Kubernetes. We’ve been working with many customers and users who have been adopting Kubernetes over the past several years. And throughout our work with them, we categorized the stages of adopting Kubernetes, especially within the enterprise into a set of five stages going from the education level to testing things in the lab or sandbox environment, to piloting a couple of applications, to taking things more on production for initial set of applications, to move advanced production purposes where you have massive migration of applications, whether the purpose is moving to the cloud or moving to microservices or revamping the environment itself, and internally utilizing the best of Kubernetes for different reasons. Now, with those various kind of stages, we’ve seen there’s an evolution or a need for various sets of functionalities especially around Kubernetes networking and network security. Specifically, many of our customers who are in stages three and four, and we have many in the financial services, health care, web and more, they have a set of use cases that they’re trying to tackle that are typically not addressed by either the open source or what’s out there. And this is where Calico Enterprise comes in. You can see here from this slide that there are, excuse me, close to eight use cases that are common in those stages. And the most common three I would see are on the left-hand side where egress access controls for pods, visibility and troubleshooting is a key one. Or why customers are choosing Calico Enterprise as well as uniform enterprise security controls. Now, the fourth one, and this is the core of our discussion today, is addressing the use case around customers already have years of experience in architecture and investments in existing top-notch firewall and solutions that they have been building over the past few years. And they have those environments around Kubernetes that they’re bringing up or they’re trying to take to production. So they are faced with the challenge of how they can actually utilize their existing investment around firewalls while making sure that they are moving forward and advancing their adoption for Kubernetes. This is the exact use case that we’ll be covering today as part of our relationship and partnership with Fortinet, which is extending the firewalls to Kubernetes using Fortinet solutions as well as Calico Enterprise. Before we jump into the details of the solution, I just want to recap three or four key value-added solutions as part of Calico Enterprise that help with Kubernetes adoption. We recently announced the Calico Enterprise Multi-Cluster Management. So a lot of our customers are extending beyond just one cluster within production, to multiple clusters within the same cloud or across clouds. And with that, comes the need for an easier way to manage an integration to network and network policies and network security across multiple Kubernetes instances or clusters. So we launched this to help with that challenge. Basically, there are three core capabilities that Calico Enterprise excels in beyond, of course, the power of the open source core of what we believe in and what we provide. And those are the three pillars around security controls, access controls and visibility and troubleshooting, as I alluded to earlier. A lot of our customers want to make sure that they have the right set of security controls from a policy enforcement perspective to uniformly apply those policies across their Kubernetes clusters for compliance and other key purposes. They want to ensure that they have … As they onboard applications to Kubernetes, they have the right set of access or is given to pods to access the right set of databases that exist outside the clusters in the VPC or in the on-prem data center. And finally, a lot of the challenges that our users are seeing is that on the lack of visibility out of the box, when you talk about Kubernetes networking, there’s a lot of things that are going on. And without the proper visibility and troubleshooting capabilities in Calico Enterprise, a lot of our users are flying blind when it comes to adopting Kubernetes. The key differentiators there, I’ll try to summarize them, the policy tiering is one key functionality I wanted to bring up, which is making sure from a security control perspective, there’s a way for administrators to actually create tiers that take higher precedence in applying policies across your administrators, across your Kubernetes clusters, and do it uniformly and in audited and automated way as well. The second differentiator is around advanced flow logs. So we talked about visibility and troubleshooting. Typically, if you rely on your traditional logs, your existing network tooling, they will not provide enough and adequate context for your teams, your application teams, your system administrators to understand the actual flows and relay those flows and that data back to the actual applications running on Kubernetes. What Calico Enterprise allows you to do is actually, in addition to your traditional logs, we actually provide advanced logs for all the network streams, over-the-network traffic with then your cluster of clusters that adds more context around the pods, pod names, namespace, service names, labels and the policy that is actually enforcing or allowing or denying the traffic. Another key differentiator is around flow visualization. I’ve spoken with a lot of admins out there, a lot of users, a lot of managers out there who want to make sure that when there are issues in their network, when there are issues impacting the SLAs, their applications, they can easily understand how the traffic flows are in their environments, and pinpoint any issue, pinpoint anything that’s blocking or anything that is actually impacting the application traffic. The easiest way to do that is through this flow visualizers that gives you a very clear image of what is going on across your cluster. All right, those did not show up. Let’s switch. Now that I introduced Calico and Calico Enterprise, hopefully, you have a better sense of what we do and what the product does. Let’s talk about the previous challenge that together … Fortinet and Tigera have worked together to solve. Coming from existing network security and troubleshooting, especially if you look at the last 10, 15, 20 years around the evolution of VMs and traditional applications before containers, a lot of those workflows were long-lived. They had pretty much static IP address defined, and based on that, there was an evolution around creating parameter-based firewalling based on zones that were pretty defined, pretty static in nature, and they’re long-lived. Now, with Kubernetes, Kubernetes container test matches all that. Because you have your clusters, you have your Kubernetes clusters, and you have various applications that could be multi-tenant. If you’re a SaaS company or a health care company, you have multiple instances or an instance representing different tenants. And all are living on the same set of infrastructure that needs access, various levels of access to databases, to external services, public and private. So taking an existing approach, taking an existing firewalling and parameter-based zoning approach is going to fail [inaudible 00:25:58]. It’s going to introduce a lot of operational challenges to you and your teams, and it’s going to introduce a lot of risk because you’re going to basically introduce some manual intervention and assigning things based on static IPs and opening firewall rules that usually take longer based on some static information, and that is not the nature of Kubernetes. Kubernetes is dynamic. Therefore, there needs to be a better way to address this. This bring us to … Now, that we understood the challenge and we can describe what the challenge that a lot of our users actually brought to us, actually, a number of why we worked … One of the key reasons of why Fortinet and Tigera joined forces is because of customer ask. They’ve had existing Fortinet Secure Fabric, they have been using Calico, and they have access to basically provide solutions to help them reduce this operational complexity. With that, I want to hand it back to Ali to talk about what we’ve done and what we’re about to do as well, which is also equally exciting. Ali? Ali Bidabadi: Thank you, Nico. As Nico mentioned, at this point, we would like to present some of the integration works that we have done together between the two companies to address some of the pain points and problems that earlier were discussed. The focus of today’s presentation, and demo after that, is going to be on the Fortigate integration, which is our flagship product, by the way. Fortigate is Fortinet next-generation firewall. It’s the most well-known product, that everyone knows about Fortinet. We obviously have a lot more than just … Fortigate, however, that’s our next-generation firewall, our flagship product, as I mentioned. The focus of today’s presentation is going to be on that piece. However, this diagram summarizes the integrations between other Fortinet products as well, all Fortinet products and the Calico Enterprise, which is the commercial version of the open source Project Calico, of course. In terms of Fortigate integration, which we will have a couple more slides and we will discuss in more detail, it’s all about how we can extend the functionality of Fortigate, the whole network firewall into the Kubernetes environment, and how the integration can enable customers to define and enforce fine-grained access policy, which we’re going to talk about in the next slide. Aside from that, we also have integration with FortiManager. With FortiManager, the goal here is to use the same mechanism and capabilities of FortiManager today that customers can use to define security policies for all of their environments, for on-prem, for cloud, for basically any non-Kubernetes environment. We would like to extend that functionality into Kubernetes, meaning that we want to give ability to customers to use FortiManager as a single-pane-of-glass management to define security policies for even microservice to microservice type security policies. That’s really the key aspect of that integration, which merits probably a separate set of conversation all by itself. But I just wanted to give you a quick overview and high level view of what that integration tries to achieve. The other integration which is worth mentioning here is with FortiSIEM. I think Nico mentioned very well the whole visibility aspect of the Kubernetes network security is absolutely key for a lot of companies from financials to health care. Most organizations wants to have that capability to be able to go back in time and see what incident exactly triggered what sort of events in the system. So what breaches, potential breaches happened that caused certain alerts? Those type of logs including DNS logs, flow logs and audit logs all can be schemed via syslog and later on via FluentD to our FortiSIEM appliance, which is really our … It’s a Fortinet SIEM solution. That’s the other integration that I thought is worth mentioning that our teams have been working on. Now, specifically about integration with Fortigate, I guess maybe it’s worth taking a minute and explaining and taking a closer look at the problem statements. Again, Kubernetes workloads, as discussed and mentioned by myself and Nico earlier, are ephemeral in nature, and their IP addresses cannot be predicted. So how can a user define fine-grained access to databases and services or APIs or applications outside of his or her Kubernetes cluster? As it turns out, all or most users are required by security and database or service owners to limit access to only those individuals who need access to perform their functions, which we all know as least privileged model. And majority of existing workloads are non-Kubernetes. Even though we are seeing a very fast trend of containerizing and moving to Kubernetes, however, we all know, still, the majority of existing workloads are non-Kubernetes. It’s a fact. And your Kubernetes applications will need to communicate with those endpoints. Nearly every application has dependencies external to Kubernetes that requires some level of access control such as access requirements for databases, third party APIs and cloud services. So not every part in your cluster should be … probably may not need to be allowed access to any or all of the resources outside of the cluster. Basically, fine-grained network security controls are a hard requirement in many environments. So Calico, with that kind of intro or mentioning the problem statements, the Calico Kubernetes controller does achieve exactly solution that addresses that very pain point. And again, the Calico Kubernetes controller for Fortigate is our response to that problem, and it basically creates address groups in Fortigate and dynamically populates source IPs of pods or nodes in the Fortigate. So if you want to look at the flow, as you can see in this diagram, step one is when the application pod themselves, they come up in Kubernetes environment. And again, they’re very dynamic in nature. At any point of time, in any node in your cluster, they could come up, they could get terminated. The Calico firewall controller programs those source IPs and populates those in the Fortigate address group. After that, an admin user can use the same mechanism and the same controls and the same kind of process that they’re used to use in order to define and enforce policies that allow, deny traffic using address groups in a very similar fashion as to the non-Kubernetes policy. This is a screenshot of the address groups in Fortigate, which are managed by Tigera. As I mentioned, as part of the workflow, the Calico controller, it monitors, it watches the Kubernetes cluster and updates the access group in Fortigate any time that it needs to. So this hopefully gives you somewhat a better understanding. This is more of a visual representation of what I explained earlier. You can see it shows in the comment section that these are managed by Tigera Calico Enterprise. And so these are the address groups. It’s an indication to user that these are the address groups that they’re populated and then created by Tigera. Again, the goal, as I mentioned, was to create and give ability to users to define and enforce security policies for pods running inside the Kubernetes cluster. And in a very, I guess, high level or maybe, lack of a better term, to summarize this, it allows users to define and enforce fine-grained access policies or fine-grained network security controls which, again, is a very hard requirement in most of the environment. With that, I would like to now hand it back to Nico who can present a demo of the solution in a very live fashion. So Nico, I’ll hand it back to you now. Thank you. Nicola Kabar: Thank you, Ali. Can I switch to … Actually, let me go and talk about … Sorry, one second. Yeah. Let’s do a quick demo. Here, we have an existing Kubernetes cluster running on, in this case, it was, I believe, AKS on the public cloud. Again, this can work anywhere. And we had a namespace called Storefront, a microservice-based application running. There’s four services running, the front-end, service-1, service-2 and the back-end. The intention here is that the front-end service needs to access the Twilio APIs externally, public APIs. However, this environment is secured by Fortigate. And the challenge that we’re presented here with is that if we have a deployment for Fortinet for the front-end, we need to make sure that if we create any policies in Fortigate, however, that deployment scales, or wherever the traffic is coming from, wherever that front-end pod is running, is dynamically added in Fortigate to allow for the policy to actually allow the traffic to go through Twilio. With that, let me share my screen real quick. Hopefully, you guys can see my screen. If you haven’t seen this before, this is the Calico Enterprise dashboard. Through this dashboard real quick, we have an overview of everything that’s going on in my clusters, the type of policies that are enforced. And you can see here there’re tiers, there’s different tiers, and applying those policies. And we have a set of nodes. As you can see, those are AKS nodes in the cluster as well as what I talked to you about earlier around the flow visualizers, which is an easy way to understand exactly what’s going on with the clustered, drill into the namespaces and basically be able to see and look at the traffic labels, look at the traffic going from any service or any other service and see exactly what’s going on, if it’s allowed or denied. So just a high overview of Calico Enterprise here. Now, from a Fortigate perspective, back to our demo scenario, we have a policy, an IPv4 policy that we have created to allow Twilio. This policy is actually going to match on … The source is going to be what we call the DMZ zone where the front-end service and pod are in. All of this is Kubernetes context-aware, so the labels of Kubernetes translate to this adverse group. And we can see here that if you look at addresses, we can see here that we have down here, hopefully, you guys can see down here … Maybe I should enlarge. We can see here that DMZ address group, right now, there’s a single instance of front-end service running, a single pod, and the source of it is coming from this specific node. With this integration, what we’re going to do actually as part of the demo is scale that service from one pod to three or four and see that this is automatically … Without making any changes in Fortigate itself, we’ll see that the address group is updated. And therefore, the policy is going to automatically allow traffic coming from those pods, wherever they are and go through Fortigate, and it’s going to be allowed to hit the Twilio APIs. If we move over to my shell, and you could see here that if you look at the number of pods in this namespace, we can see that the front-end service is a single pod that’s running, and that pod is running on node zero. You could see here the last digit is zero, which matches the source IP or node or VM that is listed here in the address group. And now, we’re going to go ahead and actually scale the front-end service to, let’s say, three replicas. So three pods will be launched. And if we give it a minute, and they have been launched right now, so [inaudible 00:39:57]. They have been launched right now. You can see there’s three instances running, those three front-end service, and you can see that they’re on node zero, two and three. Therefore, we expect that if we do a refresh here, we expect that this integration between Calico Enterprise and Fortigate to automatically take care of that, and we can see here that it has. If we scale down, the same thing happens. It will update this address group dynamically, so there’s no manual intervention needed, and there’s no security risk around that because there’s no manual intervention there. So maybe let’s do that real quick. If I scale it back to one, take a look at the number of pods running, so it’s back to one. There were three here, let’s refresh and we can see, hopefully. Yep, it’s back to the original state of it. With that, I’d like to go back to wrap up our discussion here. Hopefully, that demo makes sense of the level of integration. There’s a lot more to it than just this. Again, it’s more of a quick demo for you to understand this cool integration that we have built together and what we’re planning to do similar to what Ali mentioned. I’d like to leave you with any takeaways. I’d like to leave you with at least two key takeaways. Probably a lot of this already resonates with you around to use existing parameter-based firewalls to secure Kubernetes workloads. This is going to be challenging for you. It’s going to be adding a lot of operational complexity and security risks. And actually, that is the straight use case for one of our largest financial customers where they had to actually use affinities, and they actually had to wait on their security team to poke some holes in the firewall with static IPs. And it did not scale for them and it introduced a lot of operational complexity around it. And now, with this joint Calico Enterprise and Fortinet solution with Fortigate, this challenge is addressed by automatically enforcing those zone-based security controls while integrating the Kubernetes use cases and pods and workloads into the Fortinet Security Fabric. Finally, if you want to learn more information and resources for you, if you head to www.tigera.io/partners/fortinet, there’s actually a long list of white papers and blogs and also the deployment guide so you can actually test this out. We also have a solution brief. If you would like to try Calico Enterprise, you can head over to www.tigera.io/trial and you can actually get a full instance of Calico Enterprise running on your preferred Kubernetes service. Also, ways to interact with us at Tigera as well as with Fortinet, as you can see on the bottom right box, in there. I believe that that will wrap up this discussion. We’ve tried to keep it as brief as possible and hopefully, it was informative. I see there’s a handful of questions or at least maybe four or five that I would like to address. But really appreciate the folks who have joined us so far. Hopefully, this was informative and thank you, Ali, as well for co-presenting here. With that, we’ll answer some of the questions coming from you. John: Thanks, Nico and thanks, Ali. That was a great presentation. We do have a number of questions from the audience. I’ll just read off the first one here, but our presenters can see these questions in the audience questions window on the app. The first question is “Which Fortigate products does this integration work with, for example…which Fortigate hardware, which cloud?” Nicola Kabar: That’s a great question. I can take that one. Basically, there’s no difference between your on-prem Fortigate. I can see in the question, they’re asking if it has to be hardware or VM. There’s absolutely no such requirement. It works with every form factor of Fortigate, whether it’s virtual or physical appliance. The main reason for that is the Kubernetes clusters, as we all know, are deployed across multi-cloud environments. Sometimes customers, they only need it for on-prem deployments, sometimes in a cloud, sometimes multi-cloud. That’s why we make sure it works in every form factor because a lot of customers have existing hardware, Fortigate. So yes, it works with all of those Fortigates regardless of the form factor. John: Okay. Next question… “It’s great that you have the ability to enforce policy in the Fortigate for the Kubernetes cluster. Does this require the enterprise version of Calico, or does it work with the open source project as well?” Nicola Kabar: Great question as well. I’ll take this one. The integration between Fortigate and Calico is part of the Calico Enterprise version. Unfortunately, it’s not available in the open source version of Calico. John: Okay, thanks, Nico. Another question here, “Is there latency when the cluster scales?” Nicola Kabar: I’m not sure we’re talking about the latency of what exactly. I mean if we’re talking about the control plane updates, we have a very performance … This is going too much in the weeds in here. But the firewall controller, as part of Calico Enterprise, that integrates with Fortigate is a highly performing gRPC-based connection with … that is based on the updates that the pods that they launched for the deployments that they’ve scaled. It updates the Fortigate address groups. The number of nodes is not really … or the worker nodes of the Kubernetes is not really related to the updates here. It’s mostly looking for the deployment pods based on selective labels that you can selectively use or not use. Hopefully, that answers that question. If not, please follow up with more details of exactly what you’re looking for there. John: Another question here from our audience, “Does the Fortigate integration support north-south traffic only or does it also support east-west traffic?” Ali Bidabadi: That’s a great question, again. What we discussed so far in the integration with the Fortigate, basically, the Calico controller for Fortigate, it focuses on the use case of fine-grained access policies, which means if we have pods in the cluster that need to reach out to certain endpoints but they’re spread across different nodes, at the firewall level, we make sure the right level of permissions are set without setting any over-permissive rules. So yes, I think that falls in the category of north-south. However, for east-west, there’s also an integration work that we are … It’s a work in progress we’re working on with FortiManager. And I don’t know, Nico, if you have anything else to add to that. Nicola Kabar: Yeah. I think you’ve got it, Ali. Also, please remember that Calico policies themselves, if we’re talking intra-clusters, east-west, that’s also … Traditionally, the traffic within the pods on the same nodes themselves needs to be secured. This is where Calico policies also come in place in addition to what Ali mentioned around our intent to extend this to east-west with the use of this integration with FortiManager. John: Thank you. Another question, “How does the security and network approve or disapprove flows between the controller, the Calico controller and Fortigate?” Nicola Kabar: Network approves … I’m trying to think of a way to answer that. Ali, do you have an idea or? Ali Bidabadi: We can- Nicola Kabar: I think I have an idea, but- Ali Bidabadi: Go ahead. Go ahead, please. Nicola Kabar: Just to address this, so the only thing that … First of all, maybe this is more of a technicality question. There’s a subset, a minimal subset of … Oh, sorry, minimal subset of API access, admission access that is required for the user that is created within Fortigate. We minimize it to only be able to create … or not create, update objects in address groups. So that’s the limit or the scope in which the integration requires. It’s not going to be on a manual process to approve or disapprove. Basically, you can give access to the user, to the API user that you provide for the Fortigate controller. And it can be scoped for a subset of the specific address groups that you would like the controller to take care of or update dynamically. So it’s not wide open, it’s not admin access to everything. Ali Bidabadi: I second that. Basically, it’s a very known interaction beforehand. The only requirement here is for Calico Enterprise, Calico controller to update address groups specifically and nothing else for this integration. John: Thank you, gentlemen. I have another one here, “Is the Fortigate deployed as a DaemonSet?” Ali Bidabadi: No. Fortigate is not deployed as DaemonSet. It’s actually Calico agents are deployed as DaemonSet. And of course, that’s the piece Nico can further elaborate. But in terms of Fortigate, Fortigate really, there’s no change in the Fortigate form factor. The same Fortigate devices today that customers use to protect their non-Kubernetes clusters, that’s the whole idea. They can basically extend that functionality, the whole network firewall functionality into Kubernetes without any change into the Fortigate in terms of requiring different form factor or additional Fortigate, no. The same Fortigate device can be used for that function. But I’ll let Nico elaborate on the whole DaemonSet piece. Nicola Kabar: So an upgrade sort of thing. The Calico CNI or the pods enforcement is running as a DaemonSet, but the actual controller that is in discussion today, the integration, basically, the brains behind the integration that we’re discussing today, this runs as a deployment that runs as a pod or set of pods as far as the Calico Enterprise stack itself. It’s an add-on to allow it and deploy it, and it’s just running as a pod. John: Thank you. And someone also asked, “Is this integration available today?” Nicola Kabar: Yes, absolutely. If we go back to this slide, if you go to www.tigera.io/partners/fortinet, you can see there’s a link to the docs. And in our docs, I believe there’s also some on Fortinet. But you can see the deployment guide, it is available as of Calico Enterprise 3.0 which we launched. What was it, like a month ago, John? So it’s there and you can go, and if you are a user of Calico Enterprise and Fortinet, you can go and try it out. If you would like a … If you’re not a Calico Enterprise user or customer, feel free to reach out to us. We can work with you on providing some trial licenses. You can actually set it up and see if it actually addresses your set of requirements and how to address SSU with that as well. SSU, yeah. John: Okay, thank you, Nico. Nico, Ali, I don’t see any other questions here from the audience unless you have some final remarks you’d like to add. Ali Bidabadi: I don’t know if we answered this, John, or not. But just to make sure that I didn’t miss this, someone was asking about the way that we did the integration, they’re asking if it’s API-based or non-API-based. Basically, it is API-based. So the integration, the Calico controller consumes Fortigate APIs to update address groups. And address group is really the object that is managed by Tigera. It’s not the dynamic address object, that I think in one of the questions, I noticed that. It’s actually address group is very straightforward integration. They consume our REST APIs and it’s a very dynamic integration that allows them. As they watch the Kubernetes clusters, as the Calico controller watches them, they can immediately, instantaneously update address groups based on the events happened in the Kubernetes cluster. John: Got one more question… Nicola Kabar: Yeah, “Great info there. Is step two carried out using an API core or something else? Would like to know a little about how that is integrated with Fortinet? Also, what type of address object is created?” So as Ali mentioned, this is all API-driven calls based on what’s going on in the environment. If you head to the deployment guide, we can walk you through what is required from the API user that you create in Fortigate to how you actually launch this in Calico. And what type of address object is created? I’m not … Actually, I think you pre-create the address object … oh, sorry, the address group and the object is- Ali Bidabadi: In an address group. Nicola Kabar: It is an address group, yeah. Ali Bidabadi: Correct. John: Excellent. Nicola Kabar: Hopefully, that answers the question. John: I’m just taking one last look at this here to see if there are any other questions on the list from the audience. I think we have them all. Okay. Well, great. Thank you Nico and Ali once again for an excellent presentation. Thank you to everyone who joined our webinar today. If you’d like more information about the Fortinet-Tigera integration, you can visit either of our websites, the URLs are here on the screen. We look forward to having you join us for a future webinar. Thank you. Nicola Kabar: Thank you. Ali Bidabadi: Thank you everyone.