 Thanks for joining us today. What we'll be doing is discuss some security and governance best practices for multi-tenant clusters. I'm Navin Chakrapani. I'm the director of product management at RAFE. At RAFE, I lead various product initiatives including ones involving multi-tenancy and developer self-service. Prior to RAFE, I was in various product management roles, primarily in the cybersecurity industry. Thomas, do you want to introduce yourself? Yes, Thomas. I'm a French guy. I'm a developer advocate at CISDIG. I'm mostly focused on FALCO. You will see what it is right after. And I'm so CNCF ambassador for a week now and I was SRE for almost 10 years before. Thanks, Thomas. So what we'll do today is first set the context in terms of what are the things you need to be thinking about when you're implementing multi-tenant clusters. And then we'll dive deep into two specific areas, control access. We'll talk about how Palace can help. And we'll also talk about runtime security. And Thomas will be talking about how FALCO can help you secure your Kubernetes environments. First things first, what we've seen customers do. And this is very critical for success. You need to establish clear guidelines in terms of who gets a dedicated cluster. Was this a namespace or a bunch of namespaces? The pattern that we see increasingly is that by default, application teams get namespaces, a bunch of namespaces. And only if certain conditions are met, a dedicated cluster is spun up. This helps with cluster sprawl, reduces the cost spend, which is very important. But also adds some unique challenges in terms of security and governance. And that's going to be the focus. So we'll be focusing on the infrastructure piece, the things that the platform teams mostly care about in today's session. This slide just talks about some of the reasons why we've seen customers set up dedicated clusters. And the pattern, as I mentioned, is that in case an application does not check the box against any of these, they go for a shared cluster where the application gets allocated a namespace or a bunch of namespaces. Okay, from a security and governance standpoint, this list is not exhausted, but these are the most important things that platform teams need to be thinking about. You would have seen a lot of these boxes when the New York teams presented, starting from the left, a control axis. So what does control axis essentially mean? It's bringing together three things. One is Kubernetes RBAC. Second is integration with your identity provider. And third one is secure access, making sure that your QBAP servers are securely accessed. And I'm going to be talking about this in a little more detail, how Palace can help with this. The second problem is noisy neighbor issues. Namespaces aren't isolated by default in Kubernetes. How do you make sure that namespaces belonging to one team cannot communicate with namespaces belonging to the other team? And there's a nuance as well, because you want some of these application namespaces to be communicating with namespaces. For example, could be running security tooling like Falco. You also want to enforce resource quotas to make sure that the applications don't end up consuming more resources than they should be in a shared cluster model. And at the bottom, you can see some of the open source tooling that you can use to solve some of these challenges. The third piece is policy enforcement. In addition to making sure that your parts are running with the right privileges, you also have to think about bringing in policies which ensure that the teams are labeling their resources appropriately. As an example, a container could be tagged as vulnerable. How can you easily find which team it belongs to so that your remediation is faster? You can use OPA gatekeeper or Kivono engines for this purpose. Runtime security Thomas will be talking about in more detail. The last piece is resource utilization. It's very important to track resource utilization metrics, because without that you have no clue what is appropriate from an optimization standpoint. You'll be running blind and you'll never be able to drive any cost optimization exercises. Parallels was conceptualized to help customers implement zero trust access for Kubernetes environments. So traditionally, there have been approaches. You can use a bastion, you can use jump host VPN, etc. But all of these are expensive and they're also not scalable. For example, a bastion means that you'll have to bastion model would require that you have a bastion per data center, per VPC, VPN costs a lot of money, and then you don't have any audit logs into who's doing what. So we conceptualize and introduce the Parallels tool to help solve some of these problems, because your clusters could be running in a cloud environment, it could be running in your on-premise data center. How do you enable the same experience for your end users? How do you also ensure that based on your group identity of the user in your IDP, the user automatically inherits the right kind of privileges to access Kubernetes clusters, because you want a single source of truth and typically the single source of truth is your identity provider. So Parallels has mainly two components. One is the box in the middle, the Parallels server, which is the access proxy, and you would also install a lightweight Kubernetes operator, a Parallels operator on the clusters. So this maintains a long-standing connection with the Parallels server. So your firewall teams just have to allow outbound 443, right? So there are no other things that your platform team need to allow for this to function. So let's start from left to right. So I'm going to be taking the experience of an end user in this case, but it holds good for any tooling like Argo, Flux that you could be running, which are interacting with the clusters. So end user starts running a bunch of Q-curl commands. The first thing that happens is it hits the Parallels server. The Parallels server figures out is the user authenticated and if the user is authenticated, what kind of roles and privileges should the user have on that cluster? Once the determination is made, and that determination is made as part of step two, a just-in-time service account is created, right? You can see number three, just-in-time service account. This is extremely critical because one of the challenges that organizations face is, let's say, the user moves from one org to another, or the user leaves the company. So you don't want dangling service accounts on your cluster. So how do you make sure that the service accounts on the cluster are current and you don't have any stale accounts that could potentially compromise the security? So after step four, step three, step four, the user interacts with the cluster, it's business as usual, but one of the key things that organizations also want is centralized visibility. How do you know all the Q-curl commands that the user or the tool is running against the cluster? How do you go back in time and figure out who did what in case there's a need for a forensic analysis? That's super critical and that's something that's available as part of the powerless tool. And the last one is ending the session and removing those service accounts. So there's a timer which makes sure that after a certain point of time, period of time of user inactivity, the service accounts are automatically removed from the cluster. So it ties into the story that I mentioned earlier, where you don't want dangling service accounts on the cluster at any point of time. So to summarize, wireless helps organizations implement zero trust access and implements an experience where users can securely interact with their clusters anywhere from anywhere. They could be working out of a cafe for all that you care. And this really helps ensure that your QBAP servers are protected and the rights kind of security posture is maintained. This page calls out a few resources around a palace. We don't have time for a demo today, but we have a demo booth in the project pavilion. Please do stop by in case you have any questions or you want to understand more about palace. I'll now hand the stage over to Thomas who will be talking about how Falco can help. First, we need to discuss about what is runtime security. It's not really a famous concept right now, but basically it is about all processes, all tools you can implement in your clusters, in your environments to protect your applications when they are running. So it's for the protection of yourself, of your infrastructure, especially in the military contest, because when we share resources, bad things may happen. We know that. And also protect your end users, customers and your business of course. This is with that in mind that Falco has been created a few years ago. So Falco is a sensef incubated project. It will be graduated soon. Let's keep in touch. It's cloud native in Zairdia. Behind is Falco is able to detect that the event occurred inside a container in Kubernetes or not. We have a lot of stars and so on. To do so, we collect syscalls. Basically imagine the syscalls as the API between your application and the kernel. If an application needs some resource, connection, bandwidth, memory, anything, these applications has to ask the resource through the kernel, through the API syscalls. So we collect syscalls with an eBPF probe, a modern, powerful, synchronized, by design eBPF probe. It's pretty common in the industry right now. We talk about Selom. Selom is working with eBPF. The good thing with that is by design, it's made to be secured, performant, and it's not supposed to break anything in your kernel. You don't have to inject custom code like we did before with kernel modules. And with the last versions of Falco, we also recall a query probe. A query is for compile ones run everywhere. Before we had to compile the probe for every kernel that exists. And now with the same probe, we can run Falco almost everywhere. So it works. We have the probes collecting the syscalls at the kernel space. This is the only part of the world chain which needs privileges. After that, the syscalls events are exposed in the user space and Falco is running in the user space. So by itself, Falco is not a privileged application. It's secured by this way. So we collect the events from the kernel and we are able to enrich them with some metadata. For example, pod labels, the pod name, the pod name space, or container name, container ID, container image. Because all these events are not available directly at the kernel level. And then we have a rule engine. Falco is mostly a rule engine. We have a lot of different rules. You can write your own. You can share them with the community and you can ask the community to help you with. And Falco will apply these rules over the events that have been captured by the EPPF probe. And if a suspicious event, suspicious behavior, or possible threats is detected, it will create an alert. We also have plugins. At the beginning, Falco was only able to collect syscalls and apply rules over these syscalls. And almost one year and a half, we created a plugin framework. So now Falco is technically able to ingest any stream of events you may have. So basically logs. So right now we have plugins to collect EKS logs. Basically the audit logs from the control plane in EKS. Cloud trail, GitHub events, Kubernetes, native audit logs, Docker, Twitter, it doesn't work anymore. Just say thank you to anonymous for that. Nomad, we created that plugin with Ashicorp. And in the future, we may also have a Paralyze plugin because Paralyze by itself creates audit logs. And we could ingest these audit logs in Falco, create rules over these events and alert your teams. So the global picture is that we have the EPPF probe for collecting the syscalls. We have the plugins to collect any kind of events you may have, logs, Falco with its roll engines. A set of rules and the output. By default, we are able to forward the events, the alerts into the standard route, into a file, a program. Basically it's a pipe, syslog, HTTP, or GeoPC. We provide a set of different rules, mostly 80 system rules and 40 for the audit logs, basically with the plugins. And right now we cover the most common attacks and techniques that are used by the hackers to gain privileges, to write or read some city files, to execute any strange banners in your clusters, or dockers, or Linux hosts. And same for the audit logs, we detect the execution of a shell in a pod. The creation of a coffee map, if we detect, for example, AWS credentials in a coffee map, we are able to write an alert. If you want an example of what an alert looks like, you have a global output. It's a message for us humans. We have a priority, you can filter them by priority. We have the name of the rule, the time, the timestamp, and the output fields. Basically the output fields are all elements that have been replaced in the output message. In your rule, you set a message with tokens, and these tokens will be replaced by the specific elements of the event. The condom name, the pond name, the pond name space, whatever. And you can find out all these output fields in that JSON part. And for example, when something bad is happening in psych humanities, you have a field about the name space, the pond name. And we are also able to collect the pod labels. Could be in the case, in the situation of multi-ton and cluster, you may have specific labels for customer A, customer B, or else for business unit A, business unit B. You may find which customer is impacted because we have the labels, because we have the name space. So to forward this alert into your ecosystem, we created, I did it, FALCO Cyclic. And FALCO Cyclic basically is a proxy between FALCO and your ecosystem. Right now, we have, last time I counted, 62 integration. So we collect the FALCO alerts, and you can send forward them in a fun-out mode to your message system, your chat system, to a message queue, a streaming server, and also for cold storage, and we also have functional service, serverless. So technically, you will be able to react to immediate. If you send this alert through FALCO Cyclic to Lambda Function, to connective, if you are able to write the function, you will be able to remediate in real time. Remember FALCO is running at kernel level. So technically, we see all events in near real time. So if you are able to quickly react, you could protect your infrastructure, protect your customers as fast as possible. We also have for debugging an interface, a tailor-made interface for FALCO event. It comes with FALCO Cyclic, and you can play with it at the bootstrap just to see what happens in your cluster. So technically, we have FALCO for the detection, we have FALCO Cyclic for the notification. FALCO Cyclic is also able to inject on the fly labels in the payload, in the event. So you can add some elements, some information that are not available for FALCO, like the region of your clusters, the name of your cluster, anything, and then forward to your backends, and you can also filter by priority. For example, you can send all the alerts into Elasticsearch for statistics, for nice visualizations. Then you want to awake the SRE only for alerts with a priority above critical, for example. Like for Parallels, we don't have a lot of time for a demo right now. Come to join us at the booth, F26, all links are there, and we have technically a little bit more than five minutes for the questions, if you have. And the first volunteer wins the plushie, no question, or it's yours. It's a good question, it's a common question. Basically, this is why we created FALCO Cyclic UI. It's just to give you an overview of what alerts you will receive, what you create in your cluster. So the good way to process is to just watch for after a few minutes, a few hours, and you will have to tune a little bit those rules to add some exceptions. For example, if you are running FALCO inside the EKS cluster, you will have a lot of noise about what the node itself is doing to manage the control panel, manage the cublets, and you will have a lot of noise about the reticence of the tokens for the Cervica seconds. So if you see that, you will be able to add in white lists, in whole lists, these specific elements that are technically legit. You have what is for all rules, basically, where you can add or remove. For example, we have some lists that contain only a list of IPs for really known crypto miners servers, for example. It's a YAML file, basically. No, right now we can discuss about that later. But we have a tool called FALCO CTL, FALCO control, is in charge to watch your Git repository and synchronize the rules between your Git repo and FALCO. This is how it works now. But you can change that and use anything else. In my previous company, we used ArgoCG to manage the config map with the rules. You can have as many config maps as you need. No problem with that. At the beginning, both FALCO will read inside the folder, so you can add how many YAML you need. No problem with that. If you already have a FlientD or else to collect the logs, you don't have to use FALCO psychic. But if you want to integrate more FALCOs, if you want to have more integrations, it's easier. But it depends what you already have in your ecosystem. But technically, FALCO psychic is really dumb. It's just a proxy, so it takes the events and tries to send them as fast as possible to the output. So it's a little bit quicker than using the log password. I have more questions. You really have. Sure. Thank you all.